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SUMMARY 


To  achieve  the  goals  of  Department  of  Defense  (DoD)  programs  such  as  Reliability  and 
Maintainability  (R&M)  2000  the  Air  Force  needs  to  greatly  improve  weapon  system  designs.  To 
help  meet  these  program  goals  and  improve  weapon  system  designs,  the  Air  Force  Human 
Resources  Laboratory  (AFHRL)  embarked  on  the  Reliability,  Availability,  and  Maintainability  in 
Computer-Aided  Design  (RAMCAD)  effort.  The  RAMCAD  effort  is  aimed  at  creating  a  design 
environment  that  fully  supports  reliability,  maintainability,  and  supportability  (RM&S)  issues 
through  the  use  of  computer-aided  design/computer-aided  engineering  (CAD/CAE)  workstations. 
The  goal  of  the  Boeing  Computer  Services  (BCS)  contract  is  to  create  a  design  methodology  that 
will  allow  weapon  system  designers  to  better  integrate  RM&S  issues  and  requirements  in  to 
weapon  ystem  designs. 

This  paper  covers  a  major  section  of  the  research  performed  during  the  first  year  of  the  BCS 
RAMCAD  contract.  This  paper  documents  the  design  cycle  of  a  generic  avionics  system  for 
military  applications.  BCS  attempts  to  do  this  in  such  a  way  that  it  may  be  applicable  to  any 
company  designing  avionics  devices  for  the  military.  The  research  documented  in  this  paper 
includes  only  what  is  currently  done  and  does  not  attempt  to  state  where  changes  can  be  made  to 
improve  how  RM&S  is  implemented  in  system  design.  In  addition,  it  does  not  just  focus  on  the 
parts  of  the  design  cycle  that  currently  include  the  use  of  CAD/CAE  workstations  but  attempts  to 
cover  the  complete  design  cycle  from  system  level  requirements  analysis  through  detailed  design 
and  design  evaluation.  This  paper  was  created  to  allow  BCS  to  determine  where  changes  are 
required  in  the  design  cycle  to  allow  for  true  design  optimization. 


PREFACE 


In  September  1987,  the  Air  Forces  Human  Resources  Laboratory  (AFHRL)  awarded  Boeing 
Computer  Services  (BCS)  contract  F33615-87-C-0001  to  perform  long-term  research  associated 
with  the  Reliability,  Availability,  and  Maintainability  in  Computer-Aided  Design  (RAMCAD) 
effort.  The  goal  of  the  contract  is  to  create  a  design  optimization  methodology  as  well  as  proof-of- 
concept  software  tools  for  a  computer-aided  design/computer-aided  engineering  (CAD/CAE) 
workstation  to  implement  the  methodology.  BCS  is  focusing  its  efforts  on  optimizing  an  electronic 
design  for  reliability,  testability,  performance,  and  cost  and  area  resources. 
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1.0  INTRODUCTION 


This  paper  summarizes  the  initial  results  of  Task  3.3.2. 1,  "Design  Process  Definition,”  Reliability, 
Availability,  and  Maintainability  in  Computer-Aided  Design  (RAMCAD)  Statement  of  Work  (SOW) 
(U  S.  Air  Force  contract  F33615-87-C-0001)  (Reference  1).  In  this  task,  we  described  and  analyzed 
the  process  currently  employed  to  design  avionic  systems  for  military  applications.  The  purpose  of 
this  task  was  to  develop  the  information  and  understanding  needed  to  identify  problems  (deficiencies 
and  limitations)  in  the  current  design  process,  design  methods,  and  associated  analytical  methods. 

This  task  is  part  of  RAMCAD  SOW  Task  3  3.2,  "Requirements  Analysis,”  which  defines  the  needs 
associated  with  designing  avionic  systems  for  improved  reliability,  maintainability,  and 
supportability  (RM&S).  The  information  developed  in  Task  3.3.2  is  intended  to  support  subsequent 
efforts  to  determine  specific  areas  in  which  decision  support  capabilities  for  design  and  improved 
RM&S  analytical  tools  are  needed  Task  3.3.2. 1  supports  that  objective  by  providing  a  detailed 
description  of  the  specific  tasks  and  analyses  that  are  most  often  employed  in  the  existing  design 
process. 

In  conjunction  with  determining  existing  RM&S  analysis  needs  (Task  3. 3. 2. 2,  "Identify  RM&S 
Technology  Needs”)  and  analyzing  existing  computer-aided  design  tools  (Task  3.3.3,  "Analysis  of 
CAD  Tools”),  Task  3.3.2. 1  supports  the  development  of  requirements  that  will  focus  the  research  to  be 
conducted  during  the  RAMCAD  program  at  Boeing  Computer  Services. 

1.1  TECHNICAL  APPROACH 

Section  4  2  of  the  RAMCAD  Software  Development  Program  Detailed  Research  Plan  (Reference  2) 
outlines  the  basic  approach  used  to  develop  the  information  contained  in  this  paper 

This  information  was  obtained  from  two  primary  sources:  (a)  interviews  with  senior  engineers 
involved  in  the  design  of  avionic  systems  within  The  Boeing  Company  and  (b)  a  review  of  DOD  and 
Boeing  design  related  standards  and  documents. 

Over  30  senior  engineers  were  interviewed  during  the  course  of  this  research.  Among  them  were 
specialists  in  a  variety  of  design-related  disciplines,  including  systems  engineering,  circuit  design, 
packaging,  design  assurance  (airworthiness),  manufacturing,  logistics  support,  and  computer-aided 
engineering  and  computer-aided  design  (CAE/CAD)  tool  development.  The  individuals  interviewed 
represent  a  number  of  active  design  projects,  including  the  design  of  avionic  systems  and  subsystems 
for  the  B-1B,  the  Advanced  Tactical  Fighter,  the  Small  ICBM,  and  the  Hard  Mobile  Launcher 
Weapons  Control  System  In  addition  to  discussions  with  those  involved  in  the  design  of  military 
systems,  limited  discussions  were  held  with  individuals  involved  in  the  design  of  systems  for 
commercial  applications. 

Individuals  were  selected  to  participate  in  the  interview  process  based  upon  recommendations  by 
their  peers  and  the  results  of  an  initial  screening  interview  The  selection  process  was  heavily 
weighted  toward  those  individuals  recognized  by  the  Boeing  design  community  as  particularly 
knowledgeable  in  some  aspect  of  the  avionics  design  process. 

As  noted  in  the  research  plan,  the  interviews  were  structured  to  acquire  information  in  three 
areas-individual  experience,  avionics  technology,  and  the  avionics  design  process-and  were  oriented 
toward  capturing  knowledge  in  the  area  of  the  individual’s  expertise  (eg.,  systems  engineering, 
detailed  circuit  design). 
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1.2  ORGANIZATION  OF  THE  REPORT 


The  paper  is  organized  into  several  major  sections,  as  described  in  the  following  paragraphs. 

Sections  2.0,  3.0,  and  4.0  discuss  the  design  process  from  the  viewpoint  of  an  evolving  definition  of  the 
system  to  be  designed.  These  sections  provide  a  narrative  "walk-through”  of  the  design  process, 
showing  the  sequence  in  which  tasks  are  performed  to  develop  a  detailed  description  of  an  end  item  to 
be  manufactured. 

Section  2.0  describes  the  overall  design  process  at  a  high  level.  It  describes  the  basic  design  cycle 
employed  throughout  the  design  process  and  identifies  the  top-level  tasks,  their  sequencing,  and  their 
key  deliverables. 

Sections  3.0  and  4.0  describe  the  systems  engineering  (Sec.  3.0)  and  detailed  design  (Sec.  4.0)  phases 
of  the  design  process  in  more  detail.  Section  3.0  covers  the  key  design  tasks  from  the  initial  system 
level  requirements  to  the  development  of  the  requirements  and  specifications  for  an  end  item  at  the 
level  of  a  line  replaceable  unit  (LRU).  It  covers  all  tasks  performed  in  the  DOD  conceptual  design  and 
development  and  concept  demonstration  and  validation  phases.  Sec.  4.0  describes  the  primary  design 
tasks  involved  in  taking  the  definition  of  an  LRU  arrived  at  during  the  systems  engi  ring  phase 

and  developing  from  it  the  engineering  drawings  and  manufacturing  dataset  from  w  Wn  deliverable 
units  are  subsequently  manufactured. 

It  should  be  noted  that  these  sections  focus  on  describing  the  process  as  it  actually  occurs  within  the 
aerospace  industry.  We  have  attempted  to  describe  the  constraints  and  pressures  under  which  the 
process  actually  takes  place. 

Section  5.0  discusses  some  of  the  key  design  parameters  and  constraints  considered  in  the  trade 
studies. 

Section  6.0  identifies  and  briefly  discusses  the  problem  areas,  deficiencies,  and  bottlenecks  associated 
with  the  current  design  process. 

Appendix  A  describes  in  detail  the  relationships  among  design  tasks. 

Appendix  B  describes  currently  available  design  and  analysis  tools. 

The  appendixes,  including  individual  task  and  tool  descriptions,  serve  as  reference  data  for  later 
program  tasks  and  contain  more  specific  data  about  the  various  phases  of  the  design  process.  These 
data  are  not  repeated  in  the  body  of  this  paper,  and  it  is  assumed  the  reader  will  refer  to  the 
appendixes  if  additional  detail  is  desired. 
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2.0  OVERVIEW  OF  THE  DESIGN  PROCESS 


The  current  design  process  generally  yields  successful  designs  that  meet  all  applicable  requirements 
and  specifications.  However  the  usual  approach  is  one  of  satisficing  (Reference  5),  in  that  the  goal  is  a 
design  that  meets  the  requirements  rather  than  the  best  possible  design.  Although  it  is  not  clear  that 
complete  optimization  is  possible  in  solving  a  problem  of  the  complexity  of  avionics  design,  the 
process  can  be  modified  to  yield  designs  much  closer  to  the  optimum. 

The  basic  process  employed  at  Boeing  to  design  avionics  systems  is  modeled  on  the  DOD  Systems 
Engineering  process  described  in  Reference  4.  Figure  1  indicates  the  major  phases  of  this  process  and 
the  phasing  of  the  basic  design  activities. 

2.1  BASIC  DESIGN  CYCLE 

At  the  core  of  the  avionics  design  process  is  a  basic  design  cycle.  This  cycle  consists  of  a  sequence  of 
steps  that  are  applied  iteratively  throughout  the  design  process  to  develop  successively  more  detailed 
requirements  and  descriptions  of  the  item  being  designed.  Although  not  always  performed  as 
separate  tasks  or  conducted  in  a  structured,  explicit  manner,  this  fundamental  cycle  is  the  basis  for 
the  overall  design  process. 

This  cycle  consists  of  six  major  steps: 

1  Requirements  analysis.  The  mission  and  system  requirements  are  analyzed  to  determine,  in 
more  detail,  the  functions  needed  to  meet  the  mission  and  system  requirements  and 
specifications.  Mission  and  system  requirements  are  examined  for  validity,  consistency, 
desirability,  and  attainability  with  respect  to  current  technology,  resources,  life  cycle  costs,  and 
other  constraints.  Where  possible,  quantifiable  measures  of  performance  are  established  to  guide 
and  evaluate  the  design. 

2  Functional  analysis.  Each  of  the  functions  identified  in  Step  1  is  decomposed  into  a  set  of  primary 
subfunctions  and  the  functional  requirements  applicable  to  each  subfunction  are  derived  The 
primary  tools  of  this  step  are  functional  flow  diagrams  appropriately  annotated  to  identify  and 
define  the  system  operation  and  critical  timing  sequences. 

3.  Functional  allocation.  Functional  block  diagrams  that  define  the  architecture  of  the  system  are 
derived  from  the  functional  flow  diagrams  through  a  process  in  which  each  subfunction  and  its 
associated  design  requirements  are  allocated  (assigned)  to  a  functional  block. 

4.  Alternatives  analysis  and  trade  study.  Alternative  means  of  implementing  the  required 
functions  are  proposed  and  evaluated  against  one  another.  This  indicates  the  sensitivity  of  an 
alternative  to  the  design  criteria  and  the  relative  merits  of  each  alternative.  The  alternatives 
typically  include  hardware  and  software  technology,  operational  concepts,  hardware  concepts, 
vendors,  and  architectural  alternatives  for  incorporating  a  technology. 

5.  Synthesis.  A  baseline  system  configuration  is  synthesized  from  the  most  promising  elements  of 
the  alternatives  identified  in  Step  4 

6.  Evaluation.  The  baseline  system  configuration  is  evaluated  against  the  requirements,  and  a 
decision  is  made  about  whether  changes  to  the  configuration  are  needed  at  this  level  or  whether 
the  design  process  can  proceed  to  increasing  levels  of  detail. 
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2.2  BASIC  AVIONICS  SYSTEM  DESIGN  PROCESS 


A  top-level  view  of  the  design  process  is  shown  in  Figure  2  At  this  level,  the  design  process  can  be 
envisioned  as  consisting  of  five  major  tasks:  (a)  development  of  a  baseline  system  design  concept,  (b) 
definition  of  a  set  of  requirements  for  a  deliverable  end  item  about  the  size  of  a  line  replaceable  unit 
(LRU),  (c)  design  of  the  end  item’s  basic  circuit  elements,  (d)  design  of  the  end  item’s  mechanical  and 
electronic  packaging  (physical  design),  and  (e)  determination  of  the  end  item’s  manufacturing  and 
producibility  aspects.  Figure  2  also  shows  the  major  deliverables  between  these  top-level  tasks. 
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Figure  2  Basic  Design  Process 


The  design  process  usually  begins  with  a  statement  of  need  and  a  set  of  proposed  requirements  and 
constraints  specified  by  the  customer  Requirements  are  typically  defined  or  proposed  for  system 
performance,  acquisition  cost,  availability,  and  maintainability.  Occasionally  additional 
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requirements  or  design  constraints  such  as  those  shown  in  Figure  3  are  also  imposed  or  evolve 
through  negotiations  between  the  DOD  customer  and  the  contractor 


Mission  requirements 
and  constraints 


Environmental  factors 

Ice.  Snow,  Rain,  Wind, 
Sand.Hurrvdity. 

Dust. Temperature 
extremes,  Pressure. 
Shock,  Electrostatics, 
Vibration.  Acceleration, 
Fungus.  Ozone,  Solar 
Radiation 


Mission  profile 

•  Average  mission  length 

•  Anticipated  threat 
environment 

•  Annual  system 

utilization  _ _ 

•  ^Ormal  deployment  — ► 

operations 

•  Remote  deployment 
operations 

•  Maintenance  concept 

•  Production  totals  and 
schedule 

•  Useful  life  expectancy 


Threat  description 

•  Nuclear  — p. 

•  Thermal 

•  Dust  and  ice 

•  Radiation 

•  Chemical  agents 

•  tiect'omagnet  c  pulse 

•  B'ast 

•  Debris 

•  Shock 


Design  requirements  and 
constraints 


Physical  constraints 

•  Electrical  power 
consumption 

•  Power  dissipation 

•  Structural  integrity  and 
packaging 

•  Workmanship 

•  interfaces 

•  Interchangeability 

•  Dimensional  limits 
(size,  weight) 


Figure  3  Design  Requirements. 
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Although  it  is  common  for  the  requirements  defined  by  the  customer  to  be  inconsistent  and/or 
incomplete,  a  number  of  factors  limit  the  degree  to  which  the  contractor  is  able  to  resolve  any  issues 
with  the  DOD.  Among  these  are  the  following: 

1 .  Competitive  pressures.  Once  one  contractor  accepts  the  requirements,  others  competing  for  the 
award  must  also  do  so  to  ensure  that  they  remain  in  contention. 

2.  Restrictions  in  the  procurement  process.  In  competitive  bid  situations,  interaction  between  the 
contractor  and  the  DOD  customer  is  restricted  to  a  large  degree. 

3.  Without  designing  the  system  it  is  difficult  to  define  requirements  that  are  complete,  consistent, 
and  achievable. 

Normally  a  small  group  of  experienced  system  designers  is  formed  early  in  the  systems  engineering 
phase  to  begin  developing  a  set  of  system  functional  requirements  satisfying  the  mission  needs.  This 
group  uses  the  experience  of  its  members  and  draws  on  a  variety  of  specialists  to  develop  a  system 
concept  meeting  all  the  requirements  specified  by  the  customer.  Depending  upon  program  variables 
(e  g  ,  budget,  whether  a  concept  is  proposed  by  the  customer),  the  group  may  develop  and  document 
several  alternative  concepts  that  are  then  reviewed  and  compared  by  various  supporting 
organizations 

Once  a  baseline  system  concept  has  been  agreed  to  by  all  participating  parties,  requirements  are 
defined  for  end  items  about  the  size  of  an  LRU.  With  the  help  of  specialists  from  several  design 
disciplines,  these  requirements  are  derived  from  the  overall  system  requirements  by  an  iterative 
application  of  the  basic  system  engineering  process. 

Once  a  relatively  well  defined  set  of  requirements  for  an  end  item  is  developed,  the  detailed  design  of 
the  item  begins. 

2.3  RESPONSIBILITIES  AND  ROLES 

Within  Boeing  and  most  other  aerospace  companies,  responsibility  for  the  design  is  often  shared 
among  several  organizations.  The  usual  organizations  sharing  responsibility  are  described  in  the 
following  sections 

2.3.1  Systems  Engineering 

Systems  Engineering  is  responsible  for  developing  a  system  design  concept  that  meets  the  needs  of 
the  customer  Until  the  detailed  design  effort  begins  (Section  4.0),  Systems  Engineering  orchestrates 
the  involvement  of  the  other  design  specialties  to  develop  an  overall  system  concept  and  to  resolve 
any  technical  issues  associated  with  this  concept  It  is  the  responsibility  of  this  organization  to 
ensure  that  the  system-level  and  end-item  specifications  are  consistent  and  meet  the  appropriate 
system  requirements  defined  by  the  customer 

Tabic  1  shows  the  design-related  tasks  performed  by  Systems  Engineering  during  each  of  the  phases 
in  the  DOD  acquisition  life  cycle.  Figure  4  shows  the  interaction  between  Systems  Engineering  and 
major  design  functions. 
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Figure  4  Systems  Engineering  Functional  Interfaces 


2.3.2  Circuit  Design 

The  primary  role  of  Design  Engineering  (circuit  design)  is  to  complete  the  detailed  design  of  the  end 
item’s  electronics.  During  the  initial  phases  of  the  design  process,  this  organization  assists  Systems 
Engineering  in  developing  a  feasible  system  concept  and  derives  requirements  and  specifications  for 
the  end  items  based  upon  this  concept. 

Table  2  shows  the  design-related  tasks  performed  by  Design  Engineering  during  each  of  the  phases  in 
the  DOD  acquisition  life  cycle  Figure  5  show.,  the  information  interchange  between  Design 
Engineering  and  the  other  major  design  fun<  dons 
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TABLE  2.  Design  Activities  by  Phase-Circuit  Design 
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Figure  5.  Detailed  Design  Functional  Interfaces 


2.3.3  Design  Assurance 

Design  Assurance’s  role  during  the  design  process  is  to  ensure  that  certain  airworthiness  and 
operational  criteria  are  satisfied.  Typically,  this  involves  assessing  the  reliability,  safety,  and  fault¬ 
monitoring  capabilities  of  the  system  concept  and  the  end-item  designs  and  the  methods  they  provide 
for  maintaining  and  verifying  the  operational  readiness  of  the  system.  During  the  initial  phases  of 
the  design  process,  this  organization  helps  Systems  Engineering  develop  a  feasible  system  concept 
and  derive  requirements  and  specifications  for  the  end  items. 

Table  3  shows  the  design-related  tasks  performed  by  Design  Assurance  during  each  of  the  phases  in 
the  DOD  acquisition  life  cycle.  Figure  6  shows  the  information  interchange  between  Design 
Assurance  and  the  major  design  functions. 
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TABLE  3.  Design  Activities  by  Phase-Design  Assurance  and  Logistics  Support 
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2.3.4  Packaging  Design 


Packaging  Engineering  is  responsible  for  the  physical  design  of  the  LRU.  During  the  initial  phases  of 
the  design  process,  Packaging  Engineering  helps  Systems  Engineering  develop  a  feasible  system 
concept  and  derive  requirements  and  specifications  for  the  end  items. 

Table  4  shows  the  design-related  tasks  performed  by  the  Packaging  Engineering  organization  during 
each  of  the  phases  in  the  DOD  acquisition  life  cycle.  Figure  7  shows  the  interaction  of  this  group  with 
the  major  design  functions. 

2.3.3  Manufacturing  Design 

Manufacturing  fabricates  the  physical  design.  Its  concern  during  the  design  process  is  the 
producibility  and  cost  of  the  design.  Manufacturing  Engineering  develops  manufacturing  and 
quality  assurance  plans  from  the  electronic  and  physical  descriptions  of  the  design  developed  by 
Design  Engineering  and  Packaging  Engineering.  During  the  initial  phases  of  the  design  process, 
Manufacturing  Engineering  assists  Systems  Engineering  in  developing  a  feasible  system  concept  and 
deriving  requirements  and  specifications  for  the  end  items. 

Table  4  shows  the  design-related  tasks  performe<  by  this  organization  during  each  of  the  phases  in 
the  DOD  acquisition  life  cycle.  Figure  8  shows  the  interaction  of  Manufacturing  Engineering  with 
the  other  major  design  functions. 

2.3.6  Logistics  Support 

The  primary  role  of  Logistics  Support  during  the  design  process  is  to  assess  the  life-cycle  support 
requirements  and  costs  of  the  system  concept  and  the  end-item  designs  Logistics  Support  is  also 
responsible  for  the  preparation  of  customer  support  material  such  as  maintenance  and  operations 
manuals.  During  the  initial  phases  of  the  design  process,  Logistics  Support  helps  Systems 
Engineering  develop  a  feasible  system  concept  and  derive  requirements  and  specifications  for  the  end 
items.  The  primary  difference  between  Logistics  Support  and  Design  Assurance  is  that  Design 
Assurance  is  concerned  with  operational  readiness  and  airworthiness  issues,  while  Logistics  Support 
concentrates  on  the  support-related  requirements  of  the  system 

Table  3  shows  the  design-related  tasks  performed  by  the  Logistics  Support  organization  during  each 
of  the  phases  in  the  DOD  acquisition  life  cycle.  Figure  6  shows  the  interaction  of  this  group  with  the 
other  major  design  functions. 
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TABLE  4.  Design  Activities  by  Phase-Packaging  and  Manufacturing 
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Figi/re  7.  Packaging  Engineering 


Figure  8  Manufacturing  Engineering 
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3.0  SYSTEMS  ENGINEERING  PHASE 


The  systems  engineering  phase  covers  requirements  definition  to  full-scale  development  (FSD)  The 
main  purpose  of  the  systems  engineering  phase  is  to  produce  specifications  containing  detailed 
requirements  and  functional  block  diagrams  for  a  system  satisfying  the  customer’s  needs.  This 
specification  is  refined  to  a  level  of  definition  that  can  provide  the  basis  for  detailed  design  of  the 
system  components.  A  major  consideration  during  this  phase  is  risk  reduction.  There  should  be  high 
confidence  that  the  specified  system  will  meet  the  requirements  and  can  be  designed  and  produced  on 
schedule  and  within  budget. 

3.1  OVERVIEW:  INITIAL  REQUIREMENTS  TO  LINE  REPLACEABLE  UNIT  DESIGN 

The  systems  engineering  function  is  repeated  at  a  series  of  levels  of  increasing  design  detail.  At  each 
level,  systems  engineering  is  a  process  of  analyzing  requirements,  proposing  solutions,  analyzing  the 
proposed  solutions  to  determine  their  relative  merit,  and  synthesizing  or  selecting  a  single  solution 
(Figure  9).  This  cycle  occurs  repeatedly  until  the  specifications  are  sufficiently  detailed  to  serve  as 
input  to  the  detailed  design  process.  The  success  of  the  effort  will  depend  on  the  completeness  and 
accuracy  of  understanding  of  the  requirements,  the  degree  to  which  the  set  of  proposed  solutions 
covers  the  design  space,  the  validity  of  the  analysis  of  these  solutions,  and  the  degree  to  which  the 
evaluation  criteria  reflect  the  customer’s  priorities. 

Consider  the  task  of  developing  a  system  for  storing  and  launching  small,  mobile  intercontinental 
ballistic  missiles  (ICBM)  Among  the  issues  considered  in  the  first  systems  engineering  phase  would 
be  the  nature  of  the  transporter,  the  type  of  storage  facilities  required,  the  means  of  launching  from 
the  transporter,  and  the  control  facilities  for  the  overall  process  Possibilities  for  the  nature  of  the 
transporter  might  include  a  rail  vehicle,  a  vehicle  on  tracks,  or  a  vehicle  on  pneumatic  tires.  Each  of 
these  could  be  designed  to  travel  between  alternative  storage  sites  in  tunnels  or  on  the  surface  After 
detailed  studies  of  alternatives  of  this  nature,  the  designers  might  settle  on  a  certain  size  and  weight 
of  missile,  a  surface  vehicle  running  on  pneumatic  tires,  and  a  control  concept  based  on  a  fiber-optic 
network  Specifications  would  be  prepared  for  each  of  these  elements,  with  particular  attention  to  the 
interfaces  between  elements  The  decisions  made  in  the  first  series  of  design  studies  give  rise  to 
derived  requirements  that  would  be  included  in  these  specifications  These  specifications  would  be 
sufficiently  detailed  that  if  a  subsystem  were  developed  to  meet  each  set  of  specifications,  the 
subsystems  would  combine  to  provide  a  small,  mobile  ICBM  reflecting  the  design  decisions  made 
during  the  first  phase  At  this  point,  the  same  process  could  be  carried  out  independently  on  each  of 
these  three  systems. 

In  this  process,  alternative  concepts  are  considered  in  sufficient  detail  to  enable  the  engineers  to 
choose  among  them  confidently  One  alternative  is  selected  and  explored  in  greater  detail  to  confirm 
that  it  can  be  produced  in  the  time  and  for  the  money  available  and  that  it  will  perform  as  intended. 
This  alternative  is  then  documented  in  a  series  of  specifications  for  the  components  of  the  system. 

Our  interest  in  this  section  is  to  document  the  types  of  studies  that  contribute  to  this  process, 
including  the  data  the  studies  are  based  on  and  the  nature  and  significance  of  their  results.  We  will 
concentrate  on  the  design  of  an  avionics  subsystem,  although  we  will  give  some  consideration  to  the 
design  studies  of  the  system  containing  the  avionics,  since  these  studies  are  the  source  of  many  of  the 
derived  requirements  levied  on  the  avionics  subsystem 

3.2  THE  SYSTEM  LEVEL 

Traditionally,  a  small  group  of  experienced  system  designers  has  been  responsible  for  the  system- 
level  design.  It  is  becoming  more  common  to  form  a  team  of  varied  experience  and  background, 
including  systems  engineers,  hardware  and  software  engineers,  manufacturing  engineers,  logistics 
engineers,  life  cycle  cost  analysis  experts,  and  experts  in  other  areas  of  particular  importance  to  the 
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Figure  9  Systems  Engineering  Process 


design  under  consideration.  It  is  often  assumed  that  the  goal  of  systems  engineering  is  to  determine 
the  system  concept  that  best  meets  the  customer’s  needs.  In  practice,  because  of  considerations  of 
schedule,  budget,  and  risk  aversion,  the  actual  goal  is  the  least  expensive,  least  risky  concept  that 
adequately  satisfies  the  customer’s  needs.  This  actual  goal  serves  the  interests  of  the  designer,  who 
has  limited  time  and  money  to  develop  a  solution  to  the  problem,  and  of  the  customer,  who  must  pay 
for  the  design  and  usually  has  a  current  need  for  the  product  of  the  design  Thus,  the  ma  jority  of 
design  at  all  levels  is  modifying  and  combining  existing  designs  to  meet  a  new  goal.  Novelty  is  high 
risk  and  potentially  high  cost  and  is  avoided  when  possible  Such  novelty  as  is  included  is  usually  a 
concept  that  has  been  refined  and  tested  in  research  and  development  efforts  so  the  risk  is  reduced  to 
acceptable  levels. 

At  the  system  level,  the  design  engineers  select  a  system  concept  and  document  it  in  a  series  of  system 
segment  specifications.  There  are  four  main  activities  at  the  system  level.  Mission  requirements 
analysis  confirms  that  the  designer  and  the  customer  agree  in  their  understanding  of  the  customer 
needs  and  translates  these  needs  into  a  complete  set  of  mission  requirements  In  functional  analysis 


18 


and  requirements  allocation,  the  system  to  be  designed  is  described  as  a  set  of  actions  and 
capabilities,  and  the  requirements  are  allocated  among  these  functions.  A  variety  of  functional 
decompositions  is  considered,  and  trade  studies  are  performed  to  provide  a  basis  for  synthesizing  the 
best  design  from  elements  of  the  alternatives  considered.  This  chosen  design  concept  is  documented 
in  the  system  segment  specifications. 

The  following  sections  describe  these  activities  in  more  detail. 

3.2.1  Mission  Requirements  Analysis 

The  initial  system  requirements  may  be  quite  vague  ("design  a  small,  mobile  ICBM  system”  or 
"design  a  replacement  for  the  B-52”).  These  requirements  are  usually  accompanied  by  a  definition  of 
a  mission  the  new  system  is  to  perform.  The  specified  customer  needs  may  also  include  performance 
criteria,  interfaces  to  other  systems,  cost  and  schedule  constraints,  and  operational  and  support 
requirements.  In  addition  to  the  specified  requirements,  there  may  be  many  implicit  requirements 
imposed  on  the  system  that  must  be  identified.  These  include  general  customer  standards  applicable 
to  all  systems;  customer  standards  applying  to  this  particular  system  because  of  its  size,  operational 
environment  (e  g.,  a  nuclear  -  war  zone),  its  mission,  etc.  ,  requirements  arising  from  various  public 
laws;  and  requirements  contained  in  the  contractor’s  standards  and  policies. 

The  systems  engineering  process  begins  by  determining  the  implicit  requirements  and  studying  the 
requirements  and  mission  definition  to  determine  if  the  mission  definition  is  complete  and  if  the 
specified  requirements  correspond  to  the  mission.  The  engineer  depends  on  experience  and 
engineering  judgment  in  carrying  out  this  process  and  elicits  the  opinions  of  other  engineers 
experienced  in  the  area  of  the  design  to  increase  the  likelihood  that  the  analysis  is  thorough  and 
accurate  The  requirements  are  expressed  quantitatively,  and  a  method  is  specified  for  evaluating  a 
candidate  design  with  respect  to  each  requirement. 

The  expressed  needs  will  usually  leave  large  areas  unspecified.  The  engineer  must  identify  those 
areas  and  help  the  customer  determine  suitable  requirements,  frequently  by  proposing  possibilities 
for  the  customer  to  choose  among  Where  there  is  a  range  of  possibilities  acceptable  to  the  customer, 
this  fact  must  be  documented  so  the  remaining  design  work  will  not  be  unnecessarily  constrained.  An 
important  task  at  this  level  is  to  distinguish  negotiable  requirements  from  those  that  must  be  met. 
This  distinction  can  be  important  later  in  the  design  process,  when  requirements  may  conflict  and  the 
designer  must  decide  which  requirements  to  meet  and  which  to  relax 

3.2.2  Functional  Decomposition  and  Requirements  Allocation 

The  first  step  in  determining  a  concept  for  a  system  that  satisfies  the  mission  requirements  is  to 
prepare  a  functional  flow  diagram  This  diagram  answers  the  question  "What  has  to  happen9”  The 
blocks  in  this  diagram  correspond  to  system  requirements.  The  next  step  of  the  process  is  preparation 
of  a  functional  block  diagram  The  functional  block  diagram  answers  the  question  "How  can  the 
events  of  the  functional  flow  diagram  be  made  to  happen?”  The  boxes  in  this  diagram  correspond  to 
design  entities.  In  reality,  these  design  processes  occur  in  parallel.  As  functional  flows  are 
considered,  some  thought  must  be  given  to  how  to  produce  them  in  order  to  keep  the  flows  realistic 
As  these  ideas  of  functional  blocks  are  pursued,  they  may  lead  the  designer  to  recognize  additional 
flows  that  are  required. 

Several  alternative  functional  flows  may  be  considered,  and  for  each  of  them,  several  functional  block 
diagrams  may  be  prepared.  There  is  no  formal  technique  for  ensuring  that  these  alternatives  are  in 
any  way  complete.  They  are  based  on  customer  requests,  comparisons  with  designs  of  similar 
systems,  and  the  experience  and  ability  of  the  design  engineers.  To  increase  the  probability  that  the 
functional  decompositions  are  complete  and  the  most  important  alternatives  are  being  considered, 
the  designers  may  call  on  other  engineers  with  particular  experience  in  some  aspect  of  the  system 
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being  developed.  Brainstorming  techniques  are  used  to  further  expand  the  range  of  alternatives 
considered. 

Once  a  functional  flow  diagram  and  a  functional  block  diagram  are  produced,  the  requirements  are 
allocated  to  the  functional  blocks.  This  allocation  has  several  roles  It  helps  ensure  that  the  design 
under  consideration  actually  meets  all  of  the  requirements  levied  on  the  system.  It  provides 
traceability  in  both  directions,  identifying  the  functional  blocks  that  satisfy  a  particular  requirement 
and  the  requirements  that  constrain  the  design  of  each  functional  block  It  also  establishes  more 
detailed  requirements  for  the  functional  blocks.  The  intent  is  to  provide  a  set  of  requirements  for  a 
system  of  functional  blocks  so  that  the  blocks  can  be  developed  in  parallel;  if  each  block  meets  its 
requirements,  the  blocks  will  combine  to  form  a  system  that  meets  the  system  requirements. 

As  the  design  and  operational  concepts  evolve,  experts  prepare  supporting  concepts  such  as  a  system 
maintenance  concept,  a  manufacturing  concept,  a  support  system  concept,  and  a  system  test  concept 
In  the  team  approach  to  design,  these  experts  are  often  part  of  the  design  team.  Otherwise,  it  is  left  to 
the  discretion  of  the  design  engineer  to  determine  when  expert  advice  is  required  and  what  expert 
should  be  called  on  to  provide  it 

3.2.3  Trade  Studies 

Once  a  set  of  alternative  functional  flows  and  functional  block  diagrams  has  been  developed,  trade 
studies  are  used  to  make  choices  among  them.  Trade  studies  are  also  used  to  determine  the 
sensitivity  of  a  proposed  design  to  variations  in  the  requirements  and  to  resolve  other  technical,  cost, 
or  schedule  issues.  The  decision  to  perform  a  trade  study  is  based  on  the  perceived  risk  associated 
with  a  decision  If  the  potential  impact  is  small,  a  choice  is  made  without  the  cost  of  a  formal  study.  If 
the  risk  is  very  great,  the  design  may  be  carried  to  a  detailed  level  in  order  to  improve  confidence  in 
the  results  of  the  study 

The  data  for  the  trade  studies  are  prepared  by  specialist  engineers  in  the  relevant  areas  I  nti!  now.  it 
has  been  up  to  the  design  engineer  to  decide  when  a  trade  stud\  is  warranted  and  if  anv  specialized 
help  was  needed,  and  to  seek  out  that  help  With  the  newer  approach  using  a  team  of  varied 
specialties,  there  is  usually  expert  opinion  available  to  determine  whether  a  trade  study  is  needed 
and  to  provide  t he  necessary  data  when  one  is  required 

Before  the  trade  studies  are  begun,  a  baseline  design  concept  is  specified  This  baseline  is  coni  inuallv 
updated  as  new  choices  are  made  on  t  he  basis  of  ongoing  analysis  T  rade  studies  are  performed  on 
many  elements  of  the  design,  and  these  elements  interact  To  avoid  a  combinatorial  explosion  in  the 
comparisons  required  in  trade  studies,  when  one  element  of  the  design  is  being  considered  all  other 
elements  are  usually  assumed  to  have  their  baseline  configuration 


Trade  studies  depend  on  estimates  of  cost,  weight,  reliability,  and  other  parameters.  For  instance. 
Manufacturing  estimates  the  production  cost  of  each  design  and  identifies  those  aspects  of  a  design 
that  contribute  disproportionately  to  this  c  ist  Similarly,  Logistics  Support  estimates  support  costs 
and  other  downstream  costs  that  may  be  necessary  for  life  cycle  cost  estimation.  The  estimates  for  a 
proposed  design  are  based  on  the  performance  of  an  existing  design  of  similar  capability  The 
engineers  draw  on  personal  experience  and  on  extensive  databases  of  historical  data  to  identify  these 
similar  existing  designs  and  to  determine  the  observed  values  of  the  parameters  of  interest  Since  the 
design  is  not  well  defined  at  this  point,  there  is  a  large  margin  of  uncertainty  in  these  estimates 

Generally  the  expressed  customer  requirements  determine  how  much  weight  is  given  in  the  trade 
studies  to  each  parameter  (e.g.,  life-cycle  cost,  production  cost,  performance,  and  reliability). 
Estimates  of  parameters  that  do  not  drive  the  design  are  important  chiefly  to  identify  unexpected 
areas  of  risk  (e.g.,  significant  impacts  on  cost,  schedule,  performance,  or  reliability). 
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Failure  Modes  Analysis.  A  standard  input  to  trade  studies  is  a  failure  modes  analysis  (FMA).  In 
this  analysis,  the  effect  on  system  operability  of  each  possible  failure  of  each  functional  block  in  each 
system  operating  mode  is  determined.  The  functional  block  diagram  used  in  this  analysis  must 
include  the  current  provisions  for  operational  status  monitoring  and  fault  detection.  A  related 
analysis  included  in  the  FMA  is  an  interface  analysis,  in  which  the  effects  of  failures  in  the  various 
interfaces  between  functional  blocks  are  determined. 

FMA  has  two  objectives: 

1.  To  ensure  that  the  fault  detection  and  fault  isolation  (FD/FI)  provisions  of  the  design  are 
adequate  to  meet  the  FD/FI  requirements  of  the  contract. 

2.  To  support  development  of  effective  system  maintenance  instructions  by  identifying  each 
potential  hardware  failure  and  determining  the  indications  that  will  be  available  to  the  system 
operators  and  maintenance  personnel. 

The  results  of  the  FMA  are  documented  in  the  failure  mode  management  concept  document,  which  is 
updated  as  design  choices  are  made  and  design  detail  is  increased 

Reliability,  Maintainability,  and  Supportabiiity  Involvement.  Reliability  engineers  prepare 
estimates  of  the  mean  time  between  failure  (MTBF)  and  mission  completion  success  probability 
(MCSP)  for  each  alternative  The  MCSP  is  the  probability  that  the  mission  objectives,  including  safe 
return,  will  be  achieved.  Estimating  MCSP  requires  an  explicit  mission  scenario  telling  how  long  the 
mission  will  last,  during  what  portion  of  the  mission  a  particular  capability  will  be  used,  and  what 
minimum  functionality  must  be  maintained  for  the  mission  to  succeed.  Within  this  scenario,  the 
effect  of  the  failure  of  each  functional  block  on  MCSP  can  be  determined 

The  likelihood  of  failure  is  estimated  for  each  functional  block  These  estimates  are  based  on  MTBF 
values  for  similar  hardware,  with  corrections  for  differences  between  the  hardware  and  for 
differences  in  operating  environment  The  reliability  engineer  draws  on  databases  of  hardware 
experience  to  find  historical  MTBF  values,  relying  on  experience  to  make  the  most  appropriate  use  of 
the  historical  data  Adjustments  for  differences  in  hardware  and  environment  are  based  on  a 
combination  of  experience  and  standard  derating  models.  If  there  is  an  overall  reliability 
requirement  on  the  design,  these  estimates  are  compared  with  that  requirement.  If  the  estimated 
reliability  does  not  meet  the  requirement,  the  reliability  engineer  can  propose  redundancy  at  critical 
points  in  the  design  and  prepare  reliability  estimates  for  the  modified  design.  The  final  estimates  of 
reliability  for  each  alternative  are  included  in  the  reliability  mathematical  model  report  This  report 
also  includes  a  description  of  the  model  used  to  derive  the  estimates  and  the  justification  for  each 
estimate 

Maintainability  engineers  prepare  similar  estimates,  with  maintainability  typically  measured  in 
terms  of  mean  time  to  repair  <  MTTR)  and  maximum  maintenance  man-hours  (MMH  maximum) 

Mean  time  to  repair  includes  the  time  to  identify  and  isolate  the  fault,  repair  the  fault,  and  verify  the 
repair  Thus  it  includes  measures  of  both  testability  and  reparability.  MMH  maximum  is  the 
maximum  time  required  to  restore  an  LRL  to  operational  status  after  a  failure  As  in  the  case  of 
reliability,  these  estimates  are  based  on  historical  data,  with  appropriate  multipliers  to  reflect 
differences  in  hardware  or  maintenance  concept  between  the  system  under  design  and  the  system  on 
which  the  historical  data  are  based 

Maintainability  requirements  are  usually  expressed  in  terms  of  availability.  For  instance,  a 
minimum  number  of  airplanes  must  always  be  available  for  performing  a  mission.  The  reliability 
estimates  for  a  particular  design  can  be  used  to  estimate  how  many  airplanes  will  need  repair  at  any 
time.  The  maintainability  estimates  indicate  how  long  it  is  likely  to  take  to  return  these  planes  to 
service  The  total  number  of  planes  required  in  the  fleet  to  ensure  that  the  minimum  number  is 
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always  available  can  be  estimated  from  the  reliability  and  maintainability  projections. 
Maintainability  estimates,  along  with  indications  of  the  methods  used  to  obtain  them  and  the  data 
supporting  them,  are  included  in  a  maintainability  design  criteria  document. 

Early  in  the  design  process,  logistics  engineers  analyze  the  system  requirements  and  prepare  a  use 
study  based  on  an  analysis  of  system  functional  requirements.  This  analysis  identifies  system 
functions  and  the  support  and  secondary  functions  they  imply.  The  use  study  reflects  the  way  the 
system  will  actually  be  used  in  practice  and  is  the  lasis  for  all  supportability  estimates.  These 
estimates  include  such  things  as  personnel  levels,  skills,  tools,  and  facilities  required  for  maintenance 
and  readiness  and  spares  costs,  including  handling,  storage,  and  transportation.  The  logistics 
engineers  prepare  a  system  comparative  analysis  model  for  the  system  under  design  and  use  this  to 
estimate  the  supportability  costs  of  each  alternative  being  considered. 

The  major  task  of  the  supportability  engineers  throughout  the  design  is  the  preparation  and 
maintenance  of  the  logistics  support  analysis  record  (LSAR),  a  large  database  covering  all  aspects  of 
operational  and  maintenance  data  for  the  system  being  designed.  For  the  B- 1 B,  for  instance,  this 
database  includes  over  200  separate  parameters  for  each  of  over  33,000  parts,  in  addition  to  mission 
profiles,  operating  environments,  system  requirements  and  specifications,  operational  and 
maintenance  requirements,  reliability  and  maintainability  data,  failure  modes  and  effects  analyses, 
failure  criticality  data,  maintenance  task  summaries  and  predictions,  personnel  and  support 
equipment  requirements,  training  and  technical  data  requirements,  test  procedures,  facilities 
requirements  and  utilization  plans,  support  items  (tools,  chairs,  testers,  etc  ),  transportability 
information,  and  handling  instructions. 

These  reliability,  maintainability,  and  supportability  estimates  are  included  in  the  data  supporting 
life  cycle  cost  projections  for  the  various  alternatives.  Furthermore,  the  choices  among  the 
alternatives  under  consideration  may  be  influenced  by  the  reliability  and  availability  estimates 
independent  of  the  influence  of  these  estimates  on  life  cycle  cost  projections. 

Weaknesses  of  Analyses.  An  important  aspect  of  trade  studies  comes  into  play  here.  At  the  early 
stages  of  a  design,  there  is  little  detail,  and  there  is  a  multitude  of  designs  expressing  any  design 
concept  It  is  logically  impossible  to  determine  the  quality  of  a  design  concept  more  accurately  than 
the  range  of  quality  of  all  of  the  possible  designs  expressing  the  concept.  Attempts  to  do  so  depend  on 
some  explicit  or  implicit  assumption  about  the  choices  that  will  be  made  in  elaborating  the  design 
Some  of  these,  such  as  an  assumption  that  the  worst  possible  designs  will  be  avoided,  are  usually 
justified  However,  the  point  of  a  trade  study  is  to  choose  among  plausible  alternatives  on  the  basis  of 
the  particular  requirements  of  the  system  under  design.  Basing  estimates  on  historical  data 
implicitly  assumes  that  the  basis  for  choice  is  constant  across  designs  The  resulting  projection 
reflects  a  single  point  in  a  range  of  values,  and  a  significant  part  of  the  range  corresponds  to  values  for 
various  design  parameters  that  lie  within  the  realistic  design  space 

This  dependence  on  historical  data  to  predict  the  future  is  associated  with  a  second  problem  A  major 
reason  for  performing  trade  studies  is  to  reduce  risk,  and  the  highest  perceived  risk  in  a  design  is 
often  associated  with  a  new  technology  However,  evaluation  methods  based  on  experience  with 
similar  designs  are  weakest  in  such  a  situation.  The  new  technology  has  likely  been  explored  in 
research  and  development  efforts,  but  any  historical  reliability  data  are  going  to  be  less  complete  and 
reflect  less  realistic  experience  than  similar  numbers  for  designs  with  extensive  field  use.  Thus  the 
historical  data  underlying  trade  studies  are  likely  to  be  least  reliable  in  exactly  those  situations  when 
they  are  most  important. 

Finally,  the  goal  of  concept  exploration  is  a  parameterized  concept  Ideally,  trade  studies  are  applied 
to  a  range  of  possible  values  for  the  parameters  in  question,  and  one  of  the  criteria  used  in  evaluating 
designs  is  robustness;  that  is,  insensitivity  to  small  changes  in  the  parameters  characterizing  the 
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design.  Once  again,  evaluation  methods  providing  point  analyses  based  on  historical  observations  of 
particular  design  elements  are  particularly  unsuited  to  a  trade  study  of  a  parameterized  design. 

The  success  of  these  methods  depends  heavily  on  the  conservative  nature  of  design.  In  the  end,  the 
system  being  designed  will  not  be  radically  different  from  those  providing  the  historical  data,  so  the 
estimates  based  on  the  historical  design  choices  will  not  be  unreasonably  wide  of  the  mark  in  most 
cases.  Nevertheless,  in  the  early  stages  of  the  design,  the  chief  value  of  these  estimates  is  more  in 
calling  attention  to  the  areas  of  highest  risk  of  a  particular  concept  than  in  predicting  the  actual 
value  of  any  system  parameter. 

Actual  Flow.  The  design  process  in  practice  is  not  as  linear  as  it  would  appear  from  this  description. 
As  a  result  of  trade  studies,  new  alternative  functional  flows  and  functional  block  diagrams  may  be 
developed,  perhaps  combining  the  best  parts  of  several  of  the  alternatives  studied.  Further  trade 
studies  may  be  performed  to  guide  a  choice  among  alternative  combinations.  This  process  continues 
as  long  as  the  schedule  permits.  Then  the  best  alternative  is  selected  and  evaluated  to  confirm  that  it 
meets  all  system  requirements  and  involves  acceptable  levels  of  risk  for  the  remainder  of  the  design 
and  production  process.  Because  of  this  iteration,  many  of  the  more  complex  estimates,  including 
those  of  reliability,  maintainability,  and  logistics,  may  be  performed  only  at  the  end  of  the  process, 
when  they  serve  to  confirm  choices  rather  than  to  provide  information  on  which  to  base  choices. 

3.2.4  Specification  Preparation 

The  most  important  product  of  the  system  design  effort  is  the  system  specification.  This  reflects  the 
outcome  of  the  trade  studies  and  defines  the  system  as  a  combination  of  subsystems  corresponding  to 
the  blocks  in  the  functional  block  diagram 

The  specification  details  the  constraints  and  allocated  requirements  on  each  subsystem  Many  of 
these  requirements  are  derived  requirements  that  appear  nowhere  in  the  system  requirements  but 
must  be  met  by  the  subsystem  if  the  resulting  system  is  to  meet  the  system  requirements.  For 
example,  the  requirements  for  the  avionics  subsystem  will  include  space  budget,  weight  budget, 
cooling  concept,  cooling  budget,  and  power  budget.  It  is  unlikely  that  any  of  these  parameters  was 
defined  for  the  overall  system  They  are  all  requirements  derived  from  the  system  requirements  in 
the  context  of  the  selected  system  design  and  levied  on  the  avionics  subsystem 

In  addition  to  functional  requirements,  the  allocations  include  reliability  and  testability 
requirements  prepared  by  engineers  of  the  appropriate  specialty  These  allocations  are  based  on  the 
estimates  described  in  the  previous  section  as  they  apply  to  the  alternative  finally  selected.  These 
allocated  requirements  should  represent  the  most  achievable  distribution  among  the  subsystems  that 
will  enable  the  total  system  to  meet  its  requirements  of  reliability  and  availability. 

An  important  part  of  this  specification  is  the  definition  of  the  interfaces  among  the  functional  blocks. 
Success  in  developing  each  block  in  parallel  depends  on  the  completeness  and  accuracy  of  these 
interface  definitions.  In  addition  to  interfaces  between  subsystems,  any  interface  between  this 
system  and  any  other  system  will  be  allocated  to  one  or  more  subsystems  and  defined  in  this 
specification. 

This  specification  should,  but  rarely  does,  discuss  alternatives  considered,  trade  studies  performed, 
and  the  basis  for  the  choices  that  were  made  This  information  can  help  to  clarify  the  specification  It 
can  also  save  time  if  changes  in  requirements  or  unforeseen  problems  cause  some  portion  of  the 
system  design  to  be  modified  in  the  future. 
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3.3  THE  AVIONICS  SUBSYSTEM  LEVEL 

Each  of  the  subsystems  described  in  the  specification  produced  by  the  system-level  effort  becomes  a 
separate  design  problem  for  the  next  level.  If  the  system  being  designed  is  an  airplane  or  missile,  one 
of  the  subsystems  will  be  the  avionics  subsystem.  We  have  chosen  to  concentrate  on  this  subsystem  in 
describing  the  remainder  of  the  design  process. 

The  avionics  subsystem  will  be  designed  by  a  group  of  six  to  ten  engineers  with  experience  in  this 
activity.  Since  there  will  be  a  design  team  for  each  subsystem,  some  new  people  must  be  added  to 
those  composing  the  system  design  team.  In  practice,  the  skills  required  are  different,  so  an  entirely 
new  group  of  designers  may  be  involved.  In  the  case  of  the  avionics  subsystem,  most  of  the  design 
engineers  will  be  avionics  specialists,  and  the  other  members  may  be  particularly  experienced  in  the 
application  of  their  specialty  to  avionics  design. 

The  systems  engineering  process  will  go  through  the  same  four  steps  as  the  overall  system.  The 
designers  analyze  the  subsystem  requirements  to  determine  that  they  are  complete  and  ensure  that 
they  are  understood  accurately.  The  designers  next  perform  a  functional  analysis  to  identify 
alternative  concepts  for  realizing  the  design.  They  use  trade  studies  to  choose  among  the  alternatives 
proposed  and  to  validate  the  final  choice.  Finally,  they  document  this  choice  in  a  set  of  specifications 
at  the  LRU  level. 

3.3.1  Requirements  Analysis 

The  subsystem  requirements  are  more  detailed  and  more  complete  than  was  likely  the  case  at  the 
system  level  However,  the  main  goals  of  this  step  -  to  ensure  that  the  requirements  are  accurately 
understood  and  to  determine  that  the  requirements  are  complete  -  are  the  same  In  particular,  there 
are  usually  many  requirements  such  as  military  standards  that  apply  to  a  design.  It  is  likely  that 
some  specialized  requirements  that  were  unknown  to  the  system  designers  will  be  recognized  by  the 
avionics  subsystem  designers.  For  instance,  if  an  avionics  system  is  to  be  used  in  a  nuclear  war  zone, 
various  military  standards  specify  numerous  detailed  hardware  requirements  that  the  design  must 
meet.  These  standards  would  be  known  to  engineers  specializing  in  avionics  but  could  be  overlooked 
by  the  engineers  at  the  system  level.  Once  again,  success  in  collecting  all  applicable  requirements 
depends  on  the  experience  of  the  engineers  involved. 

3.3.2  Functional  Decomposition  and  Requirements  Allocation 

Functional  decomposition  is  significantly  different  at  this  level  than  at  the  system  level  due  to  the 
additional  detail  available.  The  goal  of  design  at  the  subsystem  level  is  to  decompose  the  design  into 
a  collection  of  functional  units  at  about  the  level  of  an  LRU,  although  there  may  not  be  an  exact  one- 
to-one  mapping  between  the  functional  units  identified  at  this  level  and  the  LRUs  in  the  final  design. 
Frequently  the  customer  has  identified  a  list  of  existing  equipment  that  will  be  included  in  the  final 
design  As  a  result,  large  parts  of  the  cooling,  power,  size,  and  weight  budgets  are  fixed  and  only  a 
restricted  portion  of  the  total  design  is  available  to  adapt  to  requirements.  In  these  new  portions,  the 
engineer  draws  heavily  on  experience.  The  goal  is  to  find  existing  designs  that  satisfy  the 
requirements  or  can  conveniently  be  modified  to  do  so,  not  to  find  the  best  possible  solution  to  the 
design  problem.  The  point  is  not  that  optimum  designs  are  avoided,  but  rather  that  the  psychology  of 
design  is  to  find  a  satisfactory  solution  as  efficiently  as  possible.  Herbert  Simon  (Reference  5)  has 
referred  to  this  approach  as  "satisficing”  and  pointed  out  that  it  enables  one  to  find  satisfactory 
solutions  to  problems  that  are  too  complex  to  allow  finding  the  optimum  solution  It  is  likely  that 
satisficing  performance  requirements  is  the  optimum  technique  for  meeting  schedule  and  budget 
constraints.  A  design  based  on  existing  elements  is  faster  and  less  risky  to  produce  than  a  completely 
new  design. 
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The  first  step  in  functional  decomposition  is  frequently  a  brainstorming  session.  High-level 
functional  flow  and  functional  block  diagrams  may  be  prepared,  or  the  participants  may  make  their 
own  mental  functional  decomposition.  The  goal  of  the  brainstorming  session  is  to  produce  a  set  of 
design  possibilities,  usually  based  on  existing  designs.  The  participants  rapidly  settle  on  two  or  three 
alternatives  for  further  analysis.  Although  the  approach  to  design  performance  is  satisficing,  in  the 
sense  that  a  new  design  will  rarely  be  considered  if  an  existing  design  meets  the  requirements  or 
comes  close  to  doing  so,  there  is  some  informal  optimizing  in  determining  which  existing  designs  to 
consider  and  in  choosing  two  or  three  for  further  development.  The  avionics  problems  being 
addressed  are  rarely  completely  novel,  and  the  engineer  implicitly  draws  on  the  knowledge 
accumulated  over  years  of  solving  similar  problems  to  choose  the  best  existing  designs  to  satisfy  the 
current  requirements.  On  the  other  hand,  the  only  experience  that  can  influence  the  design  is  the 
experience  of  the  members  of  the  design  team.  It  is  likely  that  significant  portions  of  the  potential 
design  space  will  not  be  considered  because  of  the  necessary  selectivity  of  this  accumulated 
experience. 

At  this  point,  more  detailed  functional  flow  and  functional  block  diagrams  can  be  constructed  from 
the  documentation  of  the  existing  designs.  Subsystem  requirements  are  allocated  among  the 
functional  blocks  to  ensure  that  the  design  meets  the  requirements.  As  in  the  previous  stage,  this 
allocation  involves  both  requirements  specified  for  the  subsystem  and  derived  requirements  arising 
out  of  the  functional  decomposition  being  considered. 

3.3.3  Trade  Studies 

The  choice  among  various  design  alternatives  is  based  on  traoe  studies.  A  major  goal  of  the  design 
process  is  still  to  reduce  risk,  so  trade  studies  must  be  concentrated  in  the  areas  of  highest  risk  A 
trade  study  should  not  be  performed  in  areas  where  the  outcome  will  have  lit. fie  impact  on  the  cost, 
performance,  or  schedule  of  the  final  product.  There  is  no  formal  technique  for  determining  when 
trade  studies  should  be  conducted  The  ability  to  choose  weil  varies  from  engineer  to  engineer  based 
on  experience,  training,  and  aptitude 

The  chief  difference  between  the  trade  studies  performed  at  this  level  and  those  performed  at  the 
system  level  is  that  more  detail  is  available,  so  the  estimates  are  more  accurate.  Since  the  design  is 
based  to  a  large  degree  on  existing  designs,  the  estimates  can  be  based  on  the  corresponding 
parameters  in  those  designs  If  the  design  involves  modification  of  an  existing  design,  the  engineer 
estimates  the  similarity  (eg.,  "this  object  will  require  about  1.5  times  the  circuitry  of  the  existing 
design").  Cost  estimates  are  prepared  by  specialists 

A  packaging  engineer  develops  estimates  of  system  size,  weight,  hardware,  and  interfaces.  These 
estimates  are  based  on  similar  predictions  for  each  LRl.\  These,  in  turn,  are  based  on  projections  of 
the  size  and  weight  of  each  board  in  each  l.RU.  These  estimates  may  be  modified  by  nuclear  hardness 
and  survivability  requirements  On  the  basis  of  these  estimates,  the  packaging  engineer  also  predicts 
power  and  cooling  requirements  and  order  of- magnitude  packaging  engineering  costs  for  the  system. 

A  manufacturing  engineer  prepares  an  outline  manufacturing  plan  and  statement  of  work  on  the 
basis  of  the  packaging  estimates  of  size,  weight  hardware,  and  interfaces.  Based  on  these  outlines, 
the  manufacturing  engineer  predicts  manufae  uring  engineering,  tooling,  and  production  costs  for 
the  design  Manufacturing  also  estimates  the  producibility  and  testability  of  the  proposed  design. 

The  packaging  and  manufacturing  cost  estimates  contribute  to  the  production  and  life  cycle  cost 
estimates  prepared  by  Logistics  Support 

Reliability,  Maintainability,  and  Logistics  Support  provide  the  same  types  of  data  they  did  at  the 
system  level  These  estimates  address  the  ability  of  each  design  alternative  to  meet  reliability, 
maintainability,  and  testability  requirements  that  have  been  allocated  from  the  system  level. 

However,  the  estimates  are  much  firmer  at  this  stage  because  of  the  increased  level  of  detail  of  the 
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design.  They  are  still  based  on  estimates  of  similarity  to  historical  data,  but  the  granularity  is  finer, 
so  the  historical  data  are  more  accurate  and  the  similarity  can  be  determined  more  precisely 

Trade  studies  address  technical  questions.  For  example,  an  engineer  might  use  a  trade  study  to 
determine  what  level  of  redundancy  is  desirable.  Increasing  redundancy  increases  availability,  but  it 
also  increases  such  things  as  cost,  weight,  power  and  cooling  demands,  and  spares  requirements  and 
decreases  reliability  measured  as  MTBF,  since  the  added  circuitry  increases  the  number  of  potential 
failure  sites. 

A  trade  study  might  also  be  used  to  determine  whether  a  circuit  should  include  direct  monitoring  for 
fault  detection,  fault  detection  circuitry  activated  at  user  request,  or  other  options  for  fault  detection. 
Direct  monitoring  should  enable  faults  to  be  detected  soon  after  they  occur,  but  it  requires  extra 
circuitry,  which  increases  the  cost  and  complexity  of  the  final  design. 

If  the  object  being  designed  must  survive  in  a  nuclear- war  zone,  features  must  be  added  to  the  design 
to  protect  it  from  electromagnetic  pulse  (EMP1,  radiation,  and  other  effects  of  a  nuclear  blast. 
However,  each  of  these  features  provides  new  opportunities  for  failure.  Thus,  increasing  the 
probability  of  surviving  the  effects  of  a  nuclear  detonation  decreases  the  overall  availability  of  the 
object.  These  effects  must  be  estimated  as  accurately  as  possible  so  the  design  can  strike  the  best 
possible  balance  for  the  mission  at  hand. 

The  trade  studies  balance  the  costs  of  the  various  impacts  against f  he  constraints  and  requirements  of 
the  particular  design  problem  being  addressed.  These  studies  are  decided  on  the  basis  of  cost, 
schedule,  performance,  and  function,  usually  in  about  that  order.  Considerations  of  reliability, 
maintainability,  and  producibility  are  not  drivers  of  the  design.  These  specialties  are  regarded  as 
problem  identifiers  rather  than  as  design  collaborators.  They  may  require  that  a  choice  be  changed, 
but  they  do  not  participate  in  or  influence  the  actual  process  of  choosing.  The  designers'  responses  to 
such  problems  range  from  questioning  the  basis  of  the  estimate  to  modifying  the  design  to  address  the 
identified  problem.  It  is  unlikely  that  a  choice  will  be  totally  eliminated  on  the  basis  of  reliability, 
maintainability,  or  producibility  If  it  is,  the  choice  among  the  remaining  alternatives  will  once 
again  be  made  on  the  basis  of  cost,  schedule,  performance,  and  function  and  submitted  to  reliability, 
maintainability,  packaging,  and  manufacturing  engineers  for  analysis. 

3.3.4  Specification  Preparation 

Subsystem  design  is  not  a  single  linear  process.  As  a  functional  block  diagram  is  prepared  at  some 
level  of  detail,  further  analysis  of  each  block  may  become  the  task  of  an  engineer  specializing  in  that 
particular  aspect  of  avionics  For  each  functional  block  at  each  level,  a  different  engineer  is  likely  to 
take  detailed  responsibility.  This  process  results  in  an  engineering  team  whose  structure  reflects  the 
functional  tree  of  the  item  under  design 

The  avionics  subsystem  requirements  are  usually  contained  in  the  segment  specification.  At  each 
level  of  decomposition,  a  detailed  interface  definition  document  HDD)  is  prepared  for  each  interface 
between  functional  blocks  The  requirements  for  each  functional  block  are  collected  and  passed  to  the 
engineer  responsible  for  the  further  design  of  that  block.  Depending  on  the  size  of  the  system  being 
designed,  there  may  be  some  intermediate  specifications  of  portions  of  the  avionics  subsystem  and 
their  interrelationships 

The  next  formal  specification  will  be  the  configuration  item  specification  In  an  avionics  system,  each 
configuration  item  is  about  the  level  of  an  LRU .  The  development  of  specifications  at  that  level  is 
discussed  in  Section  3  4. 
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3.4  THE  EJECTOR  STORES  INTERFACE  UNIT  LEVEL 


One  of  the  LRUs  on  the  B-1B  is  the  ejector  stores  interface  unit  (ESIU)  (Reference  3),  which  is  part  of 
the  avionics  for  the  SRAM-II  weapons  system.  The  formal  specification  for  the  ESIU  is  a 
configuration  item  specification.  Ideally,  the  first  part  of  the  configuration  item  specification  is 
prepared  by  Systems  Engineering  before  detailed  design  starts.  In  practice,  there  is  extensive 
overlap  between  these  two  activities,  largely  because  of  schedule  constraints  but  also  because  the 
system’s  function  cannot  be  completed  without  some  of  the  detail  provided  by  the  hardware  design. 
The  design  may  be  carried  to  great  detail  before  the  designers  commit  to  a  novel  approach  perceived 
to  be  associated  with  high  risk. 

Although  the  Systems  Engineering  portion  of  the  configuration  item  specification  is  usually  not 
complete  when  detailed  design  begins,  some  document  is  required  to  communicate  the  LRU 
requirements  to  the  hardware  designers.  The  hardware  implementation  requirements  document 
fulfills  this  role  It  is  usually  not  a  contract  del'  verable,  although  it  is  available  to  the  customer.  It 
can  be  changed  more  readily  than  a  formal  design  deliverable  and  addresses  the  reality  that  system 
design  and  hardware  design  necessarily  proceed  in  parallel  and  support  each  other  at  this  stage.  It 
plays  the  functional  role  intended  for  the  configuration  item  specification;  the  latter  document  has 
become  largely  a  contract  formality  that  documents  the  final  design  but  plays  no  role  in  producing 
that  design 

3.4.1  Requirements  Analysis 

Implicit  requirements  that  may  not  have  been  considered  at  higher  levels  must  be  identified  at  the 
LRU  level  For  example,  the  initial  requirement  for  the  ESIU  was  to  enable  the  B- IB  to  carry 
SRAM-II  missiles.  Unstated  were  all  of  the  requirements  that  apply  to  it  because  it  is  one  or  more 
LKl’s  that  function  as  weapons  interface  units  on  the  B-1B.  These  include  genera)  requirements 
applying  to  all  BIB  programs,  special  requirements  applying  to  all  B-lB  LRUs,  and  further  special 
requirements  applying  to  B- 1 B  weapons  interface  units  These  requirements  include  such  things  as 
cooling  concepts,  size,  weight;  interface  definitions;  reliability,  availability  and  maintainability 
requirements;  and  survivability  requirements 

3.4.2  Functional  Decomposition  and  Requirements  Allocation 

The  first  major  design  decision  is  whether  to  modify  an  existing  LRU  or  design  a  new  one  The  main 
activity  at  this  stage  is  brainstorming  for  alternatives,  which  are  usually  combinations  of  newly 
designed  hardware  with  existing  hardware  or  modifications  thereof. 

For  each  option,  the  new  hardware  and  modification  of  existing  hardware  required  are  analyzed  A 
functional  design  at  the  circuit  level  and  an  1 1)1)  are  prepared  for  each  option  An  estimate  of  wires 
and  circuit  boards  is  made  for  each  alternative.  Manufacturing  cost,  power,  weight,  and  cooling  are 
estimated  on  the  basis  of  wires  and  circuit  boards.  The  design  engineers  estimate  reliability  and 
maintainability  on  the  basis  of  the  number  of  LRUs  and  circuit  boards  Weight  and  power  are 
estimated  for  each  option.  None  of  these  estimates  is  based  on  any  formal  rules  or  history.  They  are 
informed  estimates  made  largely  by  the  engineers  in  the  design  group.  For  maintainability,  for 
instance,  the  basic  rule  of  thumb  is  that  the  more  components  there  are,  the  more  likely  it  is  that  one 
will  fail  and  the  more  difficult  the  overall  design  is  to  maintain.  The  estimates  for  an  alternative  are 
documented  in  a  hardware  description  like  the  example  in  Figure  10.  On  the  basis  of  these  estimates, 
one  of  the  alternatives  is  selected  for  further  study.  In  making  this  choice,  the  most  influential 
considerations  are  still  cost,  schedule,  functionality,  and  performance. 
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Figure  10  LRU  Hardware  Description 


Up  to  this  point  in  the  design,  there  is  little  or  no  use  of  computer-aided  engineering  (CAE)  tools  to 
develop  and  document  the  design  Individual  automated  tools  are  used  for  analyses  at  various  stages, 
hut  these  are  not  integrated,  and  the  overall  design  is  not  represented  on  any  automated  system 

Once  one  alternative  is  selected,  it  is  explored  in  more  detail  At  this  point,  about  half  the  input  to  the 
design  effort  comes  from  hardware  engineers  The  main  activities  are  functional  analysis  and 
hardware  interface  definition.  To  support  these  explorations,  the  circuit  is  designed  in  some  detail 
Portions  of  it  are  developed  to  a  breadboard,  which  is  subjected  to  extensive  testing.  The  decision  of 
whetb'''-  to  carry  the  design  to  th:°  point  is  based  on  familiarity  If  part  of  the  design  is  novel  and 
there  is  some  uncertainty  about  its  development  or  behavior,  it  is  a  candidate  for  breadboarding  and 
testing.  Alternatively,  a  portion  of  the  design  may  be  entered  in  a  CAE  tool  and  tested  by  simulation. 
The  goal  is  a  design  that  can  be  produced  with  confidence 
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Derived  requirements  are  determined,  and  requirements  at  the  LRU  level  are  allocated  to  functional 
blocks  within  the  LRU.  At  this  point,  the  requirements  are  quite  detailed.  Interfaces  are  defined  in 
terms  of  content  and  timing.  The  outcome  of  this  stage  will  be  a  configuration  item  specification  or 
equivalent.  This  specification  is  the  basis  for  the  detailed  design  described  in  Section  4.0. 

3.4.3  Trade  Studies 

There  are  two  types  of  trade  studies  at  this  level.  The  early  trades,  which  form  the  basis  for  choosing 
among  alternative  designs  for  the  LRU,  were  discussed  in  Sections  3.2.3  and  3.3.3.  Once  one 
alternative  is  selected,  more  detailed  information  is  available  and  more  accurate  trade  studies  can  be 
performed  to  choose  among  possible  implementations.  At  this  stage,  there  is  no  formal  definition  of 
design  alternatives.  At  some  points  in  the  design  process,  several  options  may  be  compared.  At  other 
points,  the  designer  will  choose  the  first  option  that  works.  The  choice  depends  on  the  individual,  his 
or  her  experience,  the  schedule,  and  the  familiarity  and  criticality  of  the  funct'on. 

Trades  are  decided  on  the  ability  of  the  design  to  meet  the  requirements.  Once  again,  the  driving 
considerations  are  cost,  schedule,  performance,  and  functionality.  Functionality  is  a  binary  decision 
The  design  is  acceptable  in  terms  of  functionality  as  long  as  the  requirements  are  met.  Performance 
is  a  graded  decision.  A  design  offering  more  than  the  minimal  performance  may  be  chosen, 
particularly  if  it  has  something  to  offer  in  another  area.  Failure  mode  analyses  help  determine 
where  redundancy  is  required  for  the  design  to  meet  reliability  requirements. 

As  described  in  Section  3.3.2,  manufacturing  and  packaging  engineers  contribute  to  the  cost 
estimates.  The  added  detail  available  at  this  point  means  that  these  estimates  can  be  more  accurate 
ind  detailed.  Furthermore,  packaging  engineers  produce  a  parts  list  for  the  design  and  may  also 
perform  thermal,  stress,  and  vibration  analyses.  The  added  detail  of  the  design  and  packaging 
estimates  enables  manufacturing  engineers  to  prepare  a  more  detailed  manufacturing  plan  and  make 
more  detailed  and  reliable  estimates  of  manufacturing  flows  and  costs.  The  purposes  of  the 
packaging  and  manufacturing  analyses  are  to  support  life  cycle  cost  estimation  and  to  identify 
problems  in  the  design.  Their  function  is  to  approve  the  design  from  the  perspective  of  manufacturing 
and  packaging  rather  than  to  actively  contribute  to  the  design. 

Reliability  is  a  direct  consideration  in  the  production  of  the  design  at  the  level  of  required 
redundancy.  For  instance,  if  a  function  is  required  to  survive  a  certain  amount  of  battle  damage  or  is 
critical  to  the  total  system,  redundancy  may  be  provided.  Detailed  predictions  of  reliability  (MTBF 
and  MCSP)  and  of  maintainability  (MTTRand  MMH)  are  prepared,  usually  at  the  end  of  the  process 
when  they  serve  to  confirm  rather  than  contribute  to  the  design. 

3.4.4  Specification  Preparation 

The  outcome  of  this  stage  in  the  process  is  part  of  the  configuration  item  specification  or  its  functional 
equivalent,  the  hardware  implementation  requirements  document.  The  initial  requirements  have 
been  refined  into  a  specification  on  which  a  hardware  engineer  can  base  a  design.  The  specification 
has  been  analyzed  in  sufficient  detail  to  provide  confidence  that  it  can  be  met  and  that  all  of  the 
original  design  requirements  will  be  met  by  the  specified  configuration  items  interacting  through  the 
documented  interfaces. 
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4.0  DETAILED  DESIGN 


4.1  OVERVIEW:  LRU  DESIGN 

This  section  describes  the  process  typically  employed  to  design  a  deliverable  end  item  (a  line- 
replaceable  unit  (LRU)  or  electronic  assembly  that  is  delivered  to  the  customer),  given  a  relatively 
detailed  definition  of  the  item’s  design  requirements.  To  simplify  the  description  of  the  design 
process,  the  following  discussion  is  based  on  the  process  used  to  design  the  internal  circuitry  and  the 
physical  characteristics,  both  internal  and  external,  of  an  LRU  roughly  the  size  and  complexity  of  the 
B-1B  ejector  stores  interface  unit  (ESIU)  described  in  Reference  3. 

The  design  functions  considered  part  of  the  detailed  design  process  include  (1)  developing  a  detailed 
functional  design  of  an  LRU’s  circuitry,  (2)  designing  software  and  electronic  hardware  elements  that 
implement  the  intended  functionality  of  the  LRU  (the  software  development  process  is  not  discussed), 
(3)  designing  the  physical  attributes  of  the  LRU,  and  (4)  developing  a  manufacturing  dataset  and 
plan  upon  which  the  initial  deliverable  LRUs  will  be  produced.  The  difference  between  this  phase  of 
the  design  process  and  that  discussed  in  Section  3.0  is  that  the  end  products  of  this  phase  are 
engineering  drawings,  specifications,  and  requirements  that  detail  how  the  LRU  is  to  be  built. 

Although  detailed  design  functions  are  often  performed  prior  to  full-scale  development  (FSD),  for 
example  during  the  demonstration  and  validation  (D/V)  phase  to  support  prototype  hardware 
development  or  assess  the  feasibility  of  a  design  concept,  this  report  focuses  on  the  process  and  tasks 
employed  in  the  design  of  a  deliverable  LRU.  The  term  "detailed  design”  refers  to  those  tasks 
involved  in  designing  a  deliverable  end  item  from  an  initial  definition  (requirements  and 
specifications)  of  an  LRU.  Typically,  this  includes  alt  tasks  beginning  after  the  system  design  review 
(SDR)  and  before  the  production  phase  begins.  Both  the  preliminary  design  review  (PDR)  ana  the 
critical  design  review  (CDR)  are  considered  to  occur  during  this  phase  of  the  design  process. 

A  simplified  view  of  the  detailed  design  process  is  shown  in  Figures  11  and  12.  Figure  11  shows  the 
basic  dependencies  among  the  top-level  detailed  design  functions.  Figure  12  shows  the  basic  data 
flow  between  the  major  detailed  design  tasks.  In  general ,  the  flow  of  information  is  from  circuit 
design  to  packaging  design  (and  the  supporting  analyses)  and  then  from  packaging  design  to 
manufacturing  design  (and  the  supporting  analyses).  This  figure  shows  that,  for  the  most  part,  first 
circuit  design  and  then  packaging  design  drive  the  detailed  design  process.  The  other  design 
functions  noted  in  this  figure  provide  supporting  roles.  Current  design  techniques  require  some  level 
of  circuit  definition  before  the  physical  design  can  proceed  much  beyond  the  conceptual  phase. 
Similarly,  some  level  of  physical  design  must  precede  those  tasks  in  which  manufacturing  issues  are 
addressed  or  supporting  analyses  such  as  thermal  analysis  are  performed. 

Circuit  design  includes  all  the  tasks  associated  with  defining  the  electronic  circuitry  (both  analog  and 
digital),  including  logic  design,  initial  component  selection,  test  connector  design,  and  similar  tasks. 
Packaging  includes  those  design  functions  associated  with  the  implementation  of  the  circuit  in 
hardware,  including  the  design  of  circuit  boards  (component  placement  and  routing,  board 
construction),  LRUs  (board  placement,  thermal  management),  and  mechanical  hardware  (selection  of 
connectors,  design  of  LRU  enclosure),  and  other  functions  Manufacturing  design  is  concerned  with 
ensuring  that  (1)  the  design  of  the  LRU  can  be  produced  cost  effectively  and  has  sufficient  testability 
to  support  manufacturing  acceptance  and  quality  assurance  tests  and  (2)  product  quality  can  be 
maintained. 

The  Reliability  organization  prepares  and  publishes  early  in  this  phase  of  the  effort  a  formal 
document  containing  a  reliability  design  guidelines  report  -  Reliability  Design  Criteria  and 
Requirements.  This  report  defines  guidelines  for  the  circuit  design  engineers  to  enable  them  to 
proceed  with  their  designs.  These  guidelines  include  (1)  part  selection;  (2)  part  derating;  (3) 
identification  of  undesirable  parts;  (4)  stress  analysis  requirements  and  instructions  on  how  to  fill  out 
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Figure  1 1  Basic  Design  Process 


the  stress  analysis  forms.  (5)  failure  mode  effects  analysis  forms  and  instructions;  (6)  worst  case 
analysis  and  recommendations.  (7)  acceptable  limits  on  part  electrical  power  stressingand  guidelines 
for  reselecting  parts;  (8)  general  review  of  system  compatibility,  experience  analysis  comparisons, 
simplicity  versus  complexity,  safety,  redundancy,  environments,  tolerances,  stability,  parts 
deratings,  and  degradation  prevention,  and  (9)  a  40-item  checklist  of  general  design  guidelines. 

It  should  be  noted  that  neither  Figure  1 1  nor  Figure  12  adequately  represents  the  true  magnitude  or 
complexity  of  the  design  process  or  the  difficulty  of  designing  complex  electronic  subassemblies  in 
today’s  environment.  In  some  sense,  the  number  of  design  tasks  and  the  level  of  interaction  between 
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the  basic  detailed  design  tasks  and  functions  cannot  be  effectively  shown.  Well  over  200  separate 
analyses  could  be  performed  during  the  design  of  an  LRU  the  size  and  complexity  of  the  ESIU  In 
some  cases,  the  analyses  that  are  performed  and  the  degree  to  which  they  affect  the  design  are  a 
function  of  schedule  and  cost.  The  figures  do  not  show  the  many  studies  or  analyses  that  are 
informally  conducted  to  develop  preliminary  information.  We  have  elected  to  describe  only  those 
analyses  that,  for  one  reason  or  another,  are  more  frequently  used.  It  is  not  possible,  within  the  scope 
of  this  paper,  to  fully  describe  the  constraints  and  difficulties  the  design  community  faces  in 
designing  a  complex  electronic  subassembly. 

It  should  also  be  noted  that  although  these  figures  show  specific,  distinct  tasks  and  their  sequencing, 
in  practice  the  division  between  one  task  and  another  is  less  well  defined.  Schedule  pressures  and  the 
iterative  nature  of  the  design  process  often  result  in  design  tasks  being  conducted  in  parallel  where 
they  are  shown  sequentially  or  as  one  task  where  they  are  shown  as  several. 

4.2  PRELIMINARY  LRU  DESIGN 

The  basic  subtasks  performed  within  this  task  are  shown  in  Figure  13.  Ideally,  the  initial  phases  of 
detailed  design  should  be  a  continuation  of  the  systems  engineering  effort  to  develop  detailed 
functional  requirements  and  characteristics  at  the  board  and  circuit  level  from  requirements  and 
specifications  (e  g  ,  configuration  item  specification,  part  1)  defined  at  the  LRU  level.  Depending  on 
the  state  of  the  design  (eg,  level  of  definition,  completeness,  and  consistency  of  the  requirements  and 
specifications)  and  the  involvement  of  the  detailed  designers  in  the  systems  engineering  tasks,  the 
transition  from  systems  engineering  to  detailed  design  may  be  a  smooth,  relatively  painless 
transition  or,  as  is  often  the  case,  a  chaotic  period  in  which  circuit  design  begins  without  a  complete 
and  consistent  definition  of  the  circuitry  that  must  be  designed.  This  latter  situation  often  arises  on 
projects  that  have  compressed  schedules  or  insufficient  funds  to  enable  a  thorough  and 
methodological  derivation  of  requirements  at  the  circuit  level  from  those  defined  at  the  LRU  level 
and  above  Realistic  requirements  require  the  involvement  of  designers  and  engineers  from  both 
Systems  Engineering  and  Detailed  Design  organizations.  In  practice,  the  design  of  the  circuit  logic  is 
an  iterative,  evolutionary  process  in  which  partial  solutions  are  proposed  and  then  evaluated  against 
the  requirements  This  becomes  particularly  difficult  when,  in  general,  several  system  engineers, 
circuit  designers,  packaging  designers,  and  manufacturing  engineers  are  involved  to  some  degree  in 
designing  the  electronics  of  a  single  LRU 

In  any  event,  the  first  task  is  normally  to  attempt  to  become  familiar  with  the  overall  system  concepts 
and  to  understand  the  impact  of  both  the  stated  and  unstated  tie,  implied  by  reference)  requirements 
on  the  functionality  and  performance  of  the  LRU.  Ideally,  this  is  a  joint  effort  between  systems 
engineers  and  the  detailed  circuit  designer  Often,  however,  the  designer  of  the  detailed  circuit  is 
left  to  his  own  devices  to  interpret  and  understand  the  impact  of  requirements  levied  on  the  LRU  by 
Systems  Engineering. 

4.2.1  LRU  Functional  Design 

Using  a  functional  decomposition  and  analysis  approach  similar  to  that  used  during  systems 
engineering,  each  LRU  function  is  further  defined  in  terms  of  requirements  for  parallel  and  serial 
supporting  functions  that  collectively  provide  the  needed  functionality  If  necessary,  each  supporting 
function  is  further  decomposed  until  the  functions  defined  appear  to  be  at  a  level  low  enough  for 
circuit  logic  or  specific  components  capable  of  providing  the  required  functions  to  be  visualized.  The 
overall  strategy  normally  used  is  to  incrementally  develop  the  requirements  by  working  from  the 
external  interfaces  of  the  LRU  circuit  inward,  using  those  elements  of  the  design  that  exist  (eg., 
standard  circuit)  or  are  well  understood  to  both  check  and  refine  the  requirements.  In  effect, 
requirements  are  propagated  from  the  external  interfaces  of  the  LRU  to  other  elements  of  the  design 
in  the  form  of  constraints. 
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•  High  level  circuit  diagrams 

•  LRU  functional  block  diagrams 

•  LRU  functional  flow  diagrams 

•  LRU  budgets 


Packaging  trade 
studies 


Figure  13  Preliminary  LRU  Design 


For  example,  the  ESIU  "release  store”  function  is  further  defined  in  terms  of  three  supporting 
functions:  (1)  "retract  the  store-release  locking  pins”  (pins  preventing  the  inadvertent  release  of  the 
store),  (2)  "retract  the  arming  pin"  (retraction  of  the  arming  pin  arms  the  store),  and  (3)  "trigger 
squibs”  (to  eject  the  store  from  the  aircraft)  An  initial  set  of  requirements  associated  with  these 
lower  level  functions  is  developed  by  identifying  the  interfaces  associated  with  each  and  determining 
the  requirements  associated  with  each  interface  In  the  example,  external  interfaces  to  the  store  and 
to  the  electromechanical  linkages  between  the  ESIU  and  the  store  define  the  initial  requirements  for 
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the  "release  store”  function.  The  characteristics  of  the  solenoids  used  to  retract  the  locking  and 
arming  pins  define  the  voltage,  current,  and  timing  requirements  of  the  first  two  functions. 

Similarly,  the  squib  characteristics  define  requirements  for  the  "trigger  squibs”  function  Additional 
requirements  are  derived  from  the  applicable  military  and  Boeing  standards  as  the  design  progresses 
and  the  interfaces  between  circuit  elements  internal  to  the  ES1U  are  defined. 

The  difficulty  faced  by  a  detailed  design  engineer  (a  detailed  circuit,  packaging,  or  manufacturing 
designer  or  engineer)  in  trying  to  understand  the  impact  of  a  myriad  of  DOD  and  contractor 
requirements  and  regulations  on  the  design  should  not  be  underestimated.  Typically,  the  designer 
will  see  a  requirement  such  as  "95%  fault  isolation"  that  must  somehow  be  implemented  or  enabled 
in  circuitry.  Unfortunately,  guidance  is  seldom  available  on  meeting  the  requirement  or  verifying  its 
implementation  In  practice,  approaches  that  appear  compatible  with  system  requirements  and  the 
applicable  standards  are  considered  acceptable. 

4.2.2  Initial  Line  Replaceable  Unit  Partitioning 

Once  a  high-level  definition  of  the  circuit  logic  has  been  developed,  a  prei:  uinary  cut  at  partitioning 
the  logic  elements  into  major  functional  blocks  is  made  This  is  the  firs’,  .-  top  toward  designating 
which  functions  will  be  grouped  together  on  a  circuit  board  Assignment  of  functions  to  individual 
partitions  is  based  primarily  on  functional  similarity,  area  and  power  requirements,  number  of 
interfaces,  and  any  known  constraints  that  dictate  tire  physical  proximit  >  of  particular  functional 
blocks  (e.g.,  computer  processor  and  memory  should  be  on  the  same  c;rcuit  board).  If  possible,  the 
LRU  is  partitioned  so  that  the  number  of  interface  signals  between  partitions  is  minimized, 
"standard”  interfaces  (e  g  ,  a  military  standard  data  bus)  between  the  partitions  can  be  employed, 
and  each  functional  block  consumes  no  more  than  80%  of  the  average  available  board  area 

This  initial  partitioning  serves  two  purposes  First,  it  partitions  the  LRU  in  a  way  that  enables 
several  circuit  designers  to  work  on  it  concurrently  with  a  minimum  of  interaction  Second.it 
provides  an  initial  cut  at  the  circuit  board  to  enable  ( 1 !  Packaging  Design  to  assess  the  need  for 
connectors,  monitor  outputs  (e.g  ,  light  emitting  diode  ( LED)  and  liquid  crystal  display  (LCD) 
displays),  and  special  packaging  requirements  and  (2)  Design  Assurance  to  refine  the  failure  modes 
analysis  (FMA)  initiated  during  systems  engineering 

If  the  program  schedule  and  resources  permit,  trade  studies  may  be  conducted  to  assess  the  relative 
merits  of  alternative  design  configurations  or  elements  (e.g  ,  components,  standard  circuits)  that 
provide  the  required  functionality  The  studies  seldom  follow  a  formal  procedure:  they  usually 
consist  of  informally  listing  the  advantages  and  disadvantages  of  the  alternatives  and  subjectively 
assessing  their  merits  and  are,  for  the  most  part,  undocumented  The  studies  rely  heavily  on  data 
from  previous  design  evaluations  and  often  become  a  "deselection”  process  -  identifying  factors  that 
eliminate  alternatives  -  instead  of  a  trade  study.  Decisions  at  this  stage  in  the  design  process  are  a 
function  of  the  level  of  detail  in  the  design.  Specific  components  or  standard  circuits  may  be  selected 
if  the  level  of  detail  in  the  design  permits. 

Although  the  major  drivers  at  this  stage  are  function  and  performance,  other  design  parameters  are 
considered  to  some  degree,  according  to  the  ranking  shown  in  Table  5.  This  table  gives  an  indication 
of  ways  the  detailed  designer  satisfies  the  requirements  associated  with  each  design  parameter 
Board  space,  power  allocations,  cooling  capacities,  and  weight  are  typically  allocated  to  the  LRU  level 
prior  to  this  point  by  negotiation  between  systems  engineering  and  detailed  design  engineers. 
Although  the  Detailed  Design  organization  has  a  voice  in  these  allocations,  system-level 
considerations  often  overshadow  those  at  the  LRU  level,  and  "budgets”  for  these  parameters  are  often 
less  than  requested.  For  this  reason,  these  and  other  design  parameters  are  viewed  primarily  as 
design  constraints  and  selection  or  deselection  criteria  for  the  detailed  designer.  In  most  cases,  they 
are  used  to  restrict  the  design  space  and  reduce  the  number  of  alternatives  studied  in  depth.  Only 
those  alternatives  that  appear  to  offer  designs  likely  to  fall  within  the  limits  prescribed  by  the 
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TABLE  5.  Detailed  Design  Considerations 


Parameter 

Considerations 

Function 

Alternate  implementations,  tolerances,  past  designs 

Performance 

Speed,  technology,  precision 

Input/output  specifications 

Serial  versus  parallel,  protocol,  timing,  failure  modes 

Power 

Allocation,  dissipation,  isolation 

Size 

Number  of  boards,  board  area,  future  enhancements 

Radiation 

Part  selection,  data  distribution.  nuclear/EMI/EMP,  and  fault  tolerant  features 

Fail-safe  and  safety 

Redundancy,  hardware  and  software,  mechanical  and  electronic 

Built-m  test 

Type,  technique,  on  line  or  of*  (me,  access  to  hardware,  size,  fault  detection  and 
fault  isolation 

Temperature  and  cooling 

Preliminary  layout,  sinks 

Electromagnetic  interface  and 

Part  selection,  preliminary  layout,  routing,  filtering 

electromagnetic  pulse 

- 

Shock  and  vibration 

Preliminary  layout,  technology,  part  selection 

Pressure 

High  voltage,  cooing 

Weight 

Part  selection,  part  density 

Cost 

Parts  cost,  manufacturing  cost 

Testability 

Observability,  controllability,  techniques,  design  rules,  fault  detection  and  fault 
isolation,  false  alarms 

Re  lability 

Stress  derating,  redundancy,  fault-tolerant  design,  buffering 

Mam  amability 

Testability 

Supportability 

Prefe"ed  parts  list  part  standardization 

Produob-iity 

Board  density,  design  rules 

Military  standards 

Guidelines,  design  rules 

requirements  arc  pursued  to  any  degree  Environmental  factors  such  as  radiation  and 

1  electromagnetic  pulse  or  electromagnetic  interference  limit  the  components  that  can  be  employed 

within  a  design,  introduce  additional  circuitry,  or  constrain  circuit  board  layout  and  routing 
Radiation,  for  example,  limits  part  selection  to  parts  certified  as  radiation  hardened  to  the  level  called 
out  in  the  specification  (e  g.,  core  random  access  memory  (RAM))  or  results  in  the  incorporation  of 
additional  circuitry  to  restore  operation  following  a  nuclear  burst  (e  g.,  logic  to  reload  dynamic  RAM 
from  nuclear  hardened  read  only  memory  (ROM)) 

Once  the  basic  requirements  (e  g  ,  functional,  performance,  power)  are  met,  the  reliability  and 
testability  of  the  design  are  evaluated  If  more  than  one  alternative  meets  the  basic  requirement, 
decisions  based  on  reliability,  testability,  and  other  factors  are  used  to  choose  among  them.  Design 
alternatives  appearing  to  be  inherently  more  reliable  or  testable  are  typically  chosen. 

Reliability  during  this  stage  of  the  design  is  usuailv  addressed  qualitatively  (certain  classes  and 
types  of  parts  are  believed  or  known  to  fail  more  often  than  others),  and  mean-time-between-failure 
(MTBF')  reliability  requirements  are  usually  met  by  using  components  from  an  approved  parts  list. 

►  Other  qualitative  rules  of  thumb  are  used  extensively,  such  as  choosing  design  alternatives  that 

require  fewer  components  and  using  the  latest  and  highest  quality  parts.  Reliability  is  stressed  only 
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when  new  technology  is  used;  the  reliability  requirements  specify  a  level  that,  from  past  experience, 
the  designer  feels  may  be  difficult  to  meet;  or  there  are  concerns  about  safety.  In  addition  to 
redundancy,  other  reliability  design  techniques,  such  as  parity  and  error  checking  and  correction 
(ECC),  are  considered. 

Reliability  and  maintainability  (R&M)  issues  affect  two  dimensions  of  the  design,  design  assurance 
and  field  support.  Although  R&M  issues  may  not  receive  the  priority  needed  to  ensure  that 
maintenance  and  support  costs  are  minimal,  these  issues  are  addressed  when  they  impact  design 
assurance  or  airworthiness.  Maintainability  and  supportability  are  usually  addressed  only  via 
testability  requirements  and  the  use  of  parts  and  components  that  have  met  the  requirements  of  a 
screening  process  (an  approved  or  preferred  parts  list  developed  by  the  Logistics  Support 
organization). 

Testability  is  typically  addressed  by  assessing  the  criticality  of  each  function  and  allocating  test 
points  to  functions  based  on  this  assessment.  Because  detailed  failure  data  are  seldom  available,  the 
emphasis  is  on  defining  test  points  for  all  the  critical  functions  first  and  then  adding  test  points  that 
discriminate  between  the  failure  of  one  partition  of  the  LRU  and  another.  If  a  test  connector  is 
needed,  the  initial  partitioning  of  the  LRU  takes  into  account  a  rough  estimate  of  board  area  needed 
for  a  test  connector;  generally  around  10%  of  the  average  available  board  area  is  assumed  The 
degree  to  which  testability  is  addressed  appears  to  be  highly  dependent  on  the  intended  use  of  the 
LRU  Testability  and  fault  monitoring  are  emphasized  in  any  design  that  is  part  of  a  nuclear 
weapons  system.  As  with  other  desirable  design  features,  schedule  pressures,  limited  board  area  or 
connector  size,  and/or  lack  of  an  effective  design  tool  usually  prevent  testability  from  being  as 
extensive  or  complete  as  it  could  be. 

In  many  cases,  the  first  design  that  appears  to  meet  all  the  levied  requirements  is  considered 
sufficient  Not  much  effort  is  spent  going  beyond  the  initial  design  in  any  area  because  of  schedule 
constraints  and  cost  concerns.  Managers  are  reluctant  to  expend  additional  resources  to  improve  an 
adequate  design  unless  there  is  a  high  degree  of  certainty  that  the  expenditure  will  pay  off  Except  in 
a  few  instances,  the  risk  of  expending  resources  without  an  effective  return  outweighs  the  potential 
benefits. 

4.3  CIRCUIT  DESIGN 

The  major  tasks  involved  in  the  design  and  verification  of  the  electronic  circuitry  are  shown  by  the 
shaded  boxes  of  Figure  14 

It  is  important  to  note  that,  in  general,  circuit  designers  are  not  concerned  with  circuit-board  issues 
while  developing  the  detailed  circuit  logic  Maintainability  or  supportability  issues  are  also  not 
considered  to  any  degree  at  the  circuit  and  component  level. 

4.3.1  Detailed  Circuit  Design 

Once  a  high  level  circuit  description  has  been  developed  and  an  initial  partioning  of  the  LRU  has 
been  completed,  detailed  design  of  the  electronic  circuitry  begins  in  earnest  The  basic  process  for 
developing  the  applicable  design  requirements  and  constraints  is  essentially  the  same  as  that 
employed  for  the  LRU  -  an  analysis  of  the  requirements  associated  with  each  function  allocated  to  the 
partition  and  the  interfaces  the  function  requires.  The  interfaces  associated  with  each  function 
allocated  to  the  partition  are  reviewed  to  determine  whether  they  have  changed  during  the  time  it 
took  to  get  to  this  point. 
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Figure  15  Detailed  Circuit  Design 


.39 


Although  Figure  14  indicates  that  detailed  circuit  design  does  not  begin  until  a  preliminary  design  of 
the  LRU  is  complete,  these  two  tasks  may  actually  occur  in  parallel.  Figure  15  shows  the 
relationship  of  the  primary  design  tasks  involved  in  detailed  circuit  design. 

Based  on  this  information  and  the  high-level  functional  block  diagrams  developed  during  the 
preliminary  LRU  design  phase,  schematic  diagrams  are  developed  that  define  the  circuit  logic  and 
major  component  modules  (e.g.,  power  supplies).  These  diagrams  are  the  functional  equivalents  of 
the  detailed  circuit  diagrams  that  describe  the  hardware  implementation  of  the  circuit.  Instead  of 
specific  components,  however,  the  circuit  logic  is  described  in  terms  of  generic  functional  blocks  at  the 
component  level  ve.g.,  AND  gates,  OR  gates,  latching  logic  blocks,  comparator  logic  blocks). 

If  schedule  and  resources  allow,  trade  studies  or  alternatives  analyses  are  performed  to  determine  the 
best  hardware  implementation  of  the  required  functions.  Requirements  and  specifications  are 
allocated  to  the  circuit  level  from  the  LRU  level  so  that  any  restrictions  related  to  component 
selection  or  the  use  of  a  particular  technology  (e  g  ,  gallium  arsenide)  are  passed  down.  If  no 
constraints  are  specified,  the  designer  chooses  among  the  various  options  according  to  his  or  her  own 
preferences.  As  before,  the  trade  studies  are  not  a  formal  procedure  and  often  become  a  deselection 
process. 

Using  the  results  of  trade  studies  and  design  handbooks  provided  by  the  component  part  vendors, 
hardware  components  are  selected  that  meet  the  functional  and  performance  requirements  of  the 
circuit.  As  before,  other  design  parameters,  such  as  temperature,  are  used  to  deselect  components 
that  cannot  meet  all  the  design  constraints.  Within  Boeing,  the  policy  is  to  select  hardware 
components  from  a  preferred  parts  list  (PPL),  a  list  of  components  meeting  certain  minimum  criteria, 
developed  by  a  logistics  support  organization.  If  the  PPL  does  not  contain  a  needed  component,  the 
designer  must  seek  an  exception  to  use  a  component  meeting  the  circuit  requirements  but  not  on  the 
PPL 

If  the  design  requires  the  use  of  custom  integrated  circuits  (application-specific  integrated  circuits 
(ASIC))  the  process  described  above  is  repeated  at  the  microelectronic  level. 

Once  some  part  of  the  detailed  circuit  design  is  defined,  circuit  schematics,  block  diagrams,  and  other 
relevant  data  are  prepared  Any  packaging  an  1  layout  constraints,  such  as  maximum  signal  path 
lengths  or  components  that  must  be  placed  close  together  on  the  board,  are  documented.  At  the 
completion  of  an  engineering  management  review  of  the  design,  a  detailed  description  of  the  circuit  is 
released  to  the  Detailed  Packaging  Design  and  Design  Assurance  organizations  (to  continue  the  F\1A 
in  more  depth) 

Up  to  this  point,  electronic  computer-aided  design  (ECAD)  tools  have  not  played  much  of  a  role  in  the 
design  of  the  circuit. 

4,3.2  Functional  and  Performance  Verification 

As  the  detailed  design  description  evolves,  the  first  checks  normally  performed  are  verifications  of  the 
circuit’s  function  and  performance  (Figures  14  and  16).  Proposed  design  alternatives  are  informally 
evaluated  as  they  evolve  to  ensure  that  all  specifications  and  requirements  are  met. 

Simulation  and  breadboards  are  the  two  basic  approaches  to  verifying  the  functionality  and 
performance  of  a  design.  The  choice  between  breadboarding  and  simulation  is  based  on  several 
factors,  including  program  schedule,  cost,  available  personnel  and  their  skills,  simulator  hardware 
availability,  model  availability,  circuit  complexity,  and  the  design  requirements  that  must  be 
verified.  Although  simulation  is  usually  less  expensive  and  requires  less  fiowtime  than 
breadboarding,  other  factors  can  prevent  its  use.  Simulators  and  other  ECAE  and  electronic 
computer-aided  design  (ECAD)  tools  capable  of  modeling  the  functions  or  computing  the  parameters 
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Figure  16  Functional  and  Performance  Verification 

to  be  verified  must  often  be  developed  to  support  a  specific  design  effort.  Models  of  complex 
components  such  as  microprocessors  must  often  be  crafted  to  suit  a  particular  analysis  and  often  take 
from  6  months  to  a  year  to  develop  Circuits  whose  functionality  is  closely  tied  to  software  require 
that  both  the  software  and  the  hardware  be  modeled.  Circuits  incorporating  components  considered 
to  incorporate  proprietary  technology,  such  as  ASICs,  can  be  simulated  only  if  the  vendor  supplies  a 
model  of  the  device.  Models  for  these  devices  are  often  not  available  from  the  supplier  for  proprietary 
reasons,  and  th*“  circuit  can  be  simulated  only  with  actual  hardware  in  the  loop. 
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It  should  be  noted  that  current-generation  tools  evaluate  only  a  limited  number  of  parameters  and 
that  one  tool  cannot  do  everything.  Models  of  the  components  in  the  design  must  often  be  developed. 
This  is  particularly  true  if  the  design  employs  state-of-the-art  design  techniques  or  technology  These 
and  other  factors  must  be  evaluated  to  choose  the  correct  testing  method  Boeing  designers  still 
prefer  to  use  breadboarding  to  verify  the  functionality  and  performance  of  the  circuit. 

Test  procedures  and  possibly  the  test  stimulus  are  developed  by  the  designer  to  verify  the  circuit  The 
circuit  description  (all  the  input  data)  is  used  to  produce  tests  that  exercise  as  much  of  the  circuit  as 
possible.  The  tests  can  be  for  several  purposes.  A  test  could  verify  that  a  design  is  functionally  correct 
in  regard  to  the  requirements.  A  manufacturing  test  would  be  used  to  determine  whether  the  design 
was  built  con  ectly,  with  the  right  parts  in  the  right  place.  A  maintenance  test  would  be  used  to  detect 
and  isolate  failures  in  a  design.  These  tests  can  be  very  different  from  one  another  For  instance,  a 
manufacturing  test  could  be  only  a  fraction  the  size  and  complexity  of  a  maintenance  test  because  a 
manufacturing  test  may  need  to  test  only  one  function  in  each  component  to  verify  the  manufacture, 
not  every  function  in  each  part  to  verify  all  functions.  While  detailed  designers  do  not  generally 
produce  the  actual  manufacturing  test  set,  they  do  provide  the  input  needed  to  develop  the  best  test  to 
verify  ihe  design. 

Breadboard  Approach.  The  schematic  "capture”  data  outputs  of  a  circuit-design  description 
(netlist  and  parts  lists)  are  used  as  inputs  to  the  breadboard-  building  process.  Within  Boeing, 
breadboards  are  generally  created  by  Design  F.ngineering  unless  some  aspect  of  the  circuit  design 
(power  requirements,  circuit  complexity,  new  technology)  requires  the  expertise  of  a  packaging 
engineer  Usually  the  breadboards  are  fabricated  in  an  engineering  shop  instead  of  a  manufacturing 
shop  and  are  not  subject  to  the  same  quality  control  or  specification  compliance  requirements  as  a 
production  hoard 

During  development  of  the  detailed  circuit  design  and  once  the  design  schematics  are  captured, 
breadboards  of  the  entire  design  or  portions  of  the  design  are  built.  The  breadboards  are  used  by 
Design  Engineering  as  a  development  tool  to  verify  the  circuit  design  functions 

Ideally,  breadboarding  and  design  verification  are  done  before  full-scale  development  ( FSD)  units  are 
started  However,  in  many  cases  schedule  pressures  cause  the  completion  of  breadboard  fabrication 
ond  verification  to  overlap  the  start  of  FSD-unit  design.  This  can  be  expensive  if  the  breadboard 
verification  results  cause  major  changes  to  the  design,  since  FSD  units  are  more  expensive  to  design 
and  build  Thi»  is  a  risk  sometimes  taken  to  meet  schedules  Typically,  l.Rl  level  verification  is 
accompi  i'hed  with  the  aid  of  hardware  prototypes  and  preproduction  units. 

Simulation  Approach.  As  an  alternative,  hut  normally  as  an  added  task,  a  circuit  may  be 
simulated  to  verify  the  functionality  and  performance  of  the  design  For  the  most  part,  functional 
simulation  tests  only  th<>  logical  functions  of  a  design  It  does  not  generally  take  into  account  layout- 
related  factors,  such  as  trace  capacitance,  loading  effects,  or  several  other  factors  that  can  influence  a 
design---  functionality  Because  of  computer  limitations,  normally  only  a  portion  of  a  total  design  can 
be  simulated  if  results  are  needed  in  a  reasonable  time  The  biggest  problem  with  simulation  is  lack 
of  models  for  the  components  in  the  design  Model  creation  is  complex  and  time  consuming  and 
generally  cannot  he  done  by  the  design  engineer  if  the  model  is  of  a  complex  device 

The  simulation  is  performed  bv  running  a  set  of  test  vectors  through  a  design  and  recording  the 
circuit  and  component  outputs.  The  results  are  evaluated  to  check  compliance  with  requirements  and 
to  develop  enhancements  to  bring  the  design  into  compliance.  With  current  technology,  it  is  not 
feasible  to  simulate  analog  and  digital  portions  of  a  circuit  simultaneously. 
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4.3.3  Detailed  Circuit  Analysis 

After  the  circuit’s  function  and  performance  have  been  verified,  several  other  circuit-level  analyses 
are  conducted  to  assess  the  characteristics  of  the  circuit  (Figures  14  and  17).  Most  of  the  following 
tasks  are  performed  by  the  design  engineer  in  concert  with  the  development  of  the  detailed  circuit 
design.  Other  evaluations  of  the  design  (e  g.,  reliability,  maintainability,  FMA,  failure  modes  and 
effects  analysis  (FMEA),  failure  modes  effects  criticality  analysis  (FMECA),  logistics)  are  conducted 
by  other  persons  or  groups  once  the  designer  has  completed  the  design  of  the  circuit. 


Figure  17.  Detailed  Circuit  Analysis 


Timing.  Timing  analysis  is  used  to  determine  whether  a  circuit  has  a  timing-related  problem  such  as 
race  conditions  or  setup  and  hold  violations.  The  analysis  can  be  either  static  or  dynamic.  A  static 
timing  analysis  looks  at  the  time  delays  on  all  gates  and  checks  for  any  problems  that  could  be  caused 
if  the  delays  varied  over  the  predefined  range  of  delays  for  each  output.  A  dynamic  analysis  also 
checks  the  delay  variations  for  each  gate  while  the  circuit  is  being  simulated.  This  finds  timing 
problems  that  are  caused  by  the  way  a  circuit  is  operated  A  dynamic  analysis  can  be  done  on  either  a 
breadboard  or  a  simulator. 
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Worst  Case  Timing  Analysis.  Worst  case  timing  and  critical-path  timing  analysis  of  a  circuit  can  be 
performed  with  the  aid  of  either  a  breadboard  or  a  simulator,  or  as  an  analysis  of  the  timing 
specifications  and  the  circuit  description.  The  purpose  of  this  analysis  is  to  check  for  race  conditions, 
setup  and  hold  violations,  and  other  timing-related  problems  caused  by  variations  in  the  time-delay 
properties  of  components.  These  variations  can  be  caused  by  variations  in  production  quality, 
component  suppliers,  temperature,  radiation,  etc. 

Worst  Case  Analysis.  A  worst  case  analysis  is  conducted  to  assess  the  circuit’s  performance  in  the 
presence  of  variations  in  component  and  production  quality,  temperature  extremes,  radiation,  and 
other  environmental  factors.  The  purpose  is  to  verify  that  a  circuit  will  always  meet  its  performance 
requirement  under  all  operating  conditions.  For  example,  amplifier  circuits  typically  have  a  nominal 
gain  requirement  that  specifies  an  acceptable  tolerance  band. 

Component  Loading  Analysis.  Component  loading  analysis  is  used  to  compute  loads  driven  by 
each  output  of  the  components  in  a  design.  An  output  can  have  two  types  of  loading,  AC  and  DC.  AC 
loading  is  caused  by  the  capacitance  of  the  signal  traces  on  the  board  and  the  capacitance  of  the  inputs 
being  driven.  It  affects  the  time  delays  of  outputs  driving  the  load.  DC  loading  involves  checking  the 
current  requirements  of  the  inputs  being  driven  and  the  ability  of  the  output  to  drive  to  the  needed 
output  level.  Derating  specifications  from  the  Reliability  and  Parts  groups  are  used  to  decrease  the 
maximum  allowable  loading  to  give  a  margin  of  safety. 

Electrical  Stress  Analysis.  Electrical  stress  is  defined  as  the  actual  power  dissipation  over  the 
maximum  rated  power  dissipation  for  an  electronic  component.  The  actual  power  can  be  found  by 
several  means,  such  as  simulation  (generally  analog  only)  or  calculating  the  DC  loading  of  each 
output  and  getting  data  from  the  part’s  data  sheet.  A  derating  factor  is  then  used  to  limit  the 
allowable  maximum  for  an  arbitrary  safety  factor  to  increase  the  reliability  These  data  are  then  used 
in  the  piece-part  reliability  predictions. 

Testability  Analysis.  The  degree  of  testability  of  an  electronic  circuit  is  determined  by  the  ability  to 
detect  faults  and  isolate  them  to  a  specified  ambiguity  group  under  a  set  of  test  conditions.  Although 
there  are  several  approaches  to  determining  the  testability  of  a  design,  no  single  approach  is  believed 
to  be  adequate  by  itself  Among  those  normally  used  are  several  topological  checks,  such  as  checking 
for  test  point  coverage  and  discrimination;  use  of  reset  or  clear  pins  tied  to  a  set  value,  breaking  up 
counter  chains;  providing  scan  paths;  and  other  design-related  characteristics  that  can  inhibit  or 
enhance  a  design’s  testability.  These  checks  are  used  to  help  locate  areas  of  a  design  that  are  hard  to 
test  and,  in  some  cases,  aid  in  enhancing  the  testability  of  a  design.  A  formal  analysis  may  be  done  by 
Manufacturing  test  personnel,  while  the  detailed  designer  usually  does  a  more  informal  evaluation. 

Fault  Detection  and  Isolation  Analysis.  The  purpose  of  this  analysis  is  to  assess  the  ability  of  a 
test  set  to  detect  and  isolate  faults  in  the  circuit.  Generally  the  effectiveness  of  the  circuit's  fault 
detection  and  isolation  features  is  determined  by  computing  the  percentage  of  faults  that  are 
successfully  detected  and  isolated  to  a  predefined  ambiguity  group  for  a  set  of  test  vectors.  The  test 
vectors  are  developed  by  the  design  engineer  based  on  his  or  her  understanding  of  how  the  circuit 
operates.  This  analysis  provides  data  for  maintenance  documentation. 

4.4  DESIGN  ASSURANCE 

Much  of  the  design  assurance  function  is  provided  by  the  FMA,  FMEA,  and  FMECA  Figure  18 
shows  the  relationship  of  the  design  assurance  tasks  to  the  other  design  tasks  involved  in  detailed 
design. 
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4.4.1  Failure  Modes  Analysis  (Piece-Part  Analysis) 


The  failure  modes  (piece-part  or  component)  analysis  usually  follows  the  PDR.  It  is  a  process  in  which 
each  component  within  the  LRU  is  analytically  failed  (commensurate  with  its  respective  failure 
mode)  and  the  results  analyzed  to  determine  (1)  if  the  fault  is  detected  or  undetected,  (2)  the  system 
operating  mode  in  which  the  detection  would  occur,  and  (3)  the  impact  and  criticality  of  the  failure  on 
the  system.  The  analysis  can  result  in  a  redesign  of  the  operational  or  fault  detection  circuitry  to 
ensure  that  the  fault  detection  and  fault  isolation  (FD/FI)  requirements  for  each  LRU  are  met. 

Although  it  can  begin  earner  than  shown  in  Figures  18  and  19,  the  piece-part  analysis  consists  of 
identifying  and  grouping  together  components  that  would  provide  a  similar  fault  indication  if  they 
failed  in  a  respective  failure  mode.  The  results  of  this  analysis  includes  a  complete  fault  description. 


Logistics  support 
analyses 


Figure  19.  Design  Assurance 
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the  detection  mode,  system-level  indications  (how  the  fault  is  manifested  at  the  monitoring  station), 
and  system  impact  when  such  a  failure  occurs. 

The  initial  piece-part  analysis  must  to  be  completed  by  the  CDR  for  each  unit  in  the  system.  After 
the  CDR,  when  stress  data  are  available  for  the  components  of  an  LRU,  the  piece-part  analysis  is 
revised  to  incorporate  these  failure-rate-per-component  data. 

If  available,  component  failure  rate  data  are  used  to  reduce  uncertainty  about  where  the  failure 
impacts  more  than  one  LRU. 

Fault  response  sheets  (FRS)  are  used  to  document  the  planned  method  of  detecting  and  isolating 
failures,  including  any  necessary  sequencing  of  maintenance  actions.  FRS  preparation  is  initiated 
between  PDR  and  CDR  Applicable  interface  and  piece  part  analysis  data  are  condensed  and 
incorporated  into  each  FRS. 

4.4.2  Failure  Modes  and  Effects  Analysis 

The  FMEA  is  conducted  to  identify  potential  design  weaknesses  through  a  systematic,  documented 
analysis  of  all  likely  modes  of  equipment  failure,  the  causes  of  each  failure  mode,  and  the  effects  of 
each  failure  mode  FMEAs  may  be  performed  at  the  part,  component,  LRU,  subsystem,  and  system 
levels,  with  the  system-level  FMEAs  usually  receiving  the  emphasis. 

In  performing  the  FMEA,  the  following  items  are  considered. 

a  LRU  and  component  failure  modes. 

b.  Likely  causes  of  failure  (obtained  from  lower  level  FMEAs). 
c  Mission  timelines  and  mission  profiles 
d  Failure  effects  on  adjacent  components 

e.  Failure  effects  on  the  system  and  mission: 

1  Complete  loss  of  mission  objectives. 

2.  Partial  loss  of  mission  objectives 

3.  Loss  of  redundancy 

4.  Reconfiguration  of  equipment. 

5.  Potential  loss  of  life. 

f.  Potential  redundancies,  workarounds,  or  other  compensation. 


The  FMEA  methodology  involves  the  direct  participation  of  the  designer  as  well  as  that  of  reliability 
engineers  Unfortunately,  the  results  of  the  analysis  often  cannot  be  used  or  interpreted  by  people 
other  than  the  analysts  who  perform  it.  In  addition,  the  FMEA  is  often  too  fragmented, 
inappropriately  timed  (e  g  ,  the  analysis  is  performed  after  the  fact  to  fulfill  requirements  rather  than 
as  a  driver  of  the  design),  or  is  not  properly  disseminated  or  utilized  by  the  organizations  that  could 
most  benefit  from  it. 


4.4.3  Part  Screening 

Component  and  item  burn-in  is  an  economical  means  of  screening  items  to  help  improve  reliability. 
The  burn-in  tests  are  specialized  for  various  components  (integrated  circuits,  transistors  and  diodes, 
resistors  and  capacitors,  relays,  lamps,  etc.)  and  performed  to  strict  test  criteria.  These  tests  are  done 
during  the  later  stages  of  FSD  to  allow  for  qualification  of  parts  and  suppliers  to  support  overall 
reliability  effectiveness. 

4.4.4  Reliability  and  Maintainability  Analyses 

During  the  FSD  phase  of  the  design  process,  reliability  and  maintainability  (R&M)  analyses,  which 
support  the  design  and  product  assurance  activities,  shift  to  evaluating  the  design  to  determine  if  it  in 
fact  will  support  the  various  R&M  allocations  made  in  the  specifications.  The  analyses  and 
calculations  (mean  time  between  failures  (MTBF),  mean  time  to  repair  (MTTR),  maximum  man¬ 
hours  to  repair  (MMHmax),  etc.)  all  increase  in  fidelity  as  more  and  more  detailed  information  about 
the  design  becomes  available  in  FSD.  Allocations  of  reliability  and  maintainability  requirements 
down  to  the  LRU  level  are  identified,  and  predictions  for  the  LRUs  as  designed,  as  well  as  analyses 
relating  to  the  trade  studies  and  reliability  and  maintainability  problems  and  concerns,  are  reported 
in  reliability  allocations,  assessments,  and  analysis  (RAAA)  and  maintainability  allocations, 
assessments  and  analysis  (MAAA)  reports. 

Data  collection  and  reporting  become  a  large  portion  of  the  R&M  task  to  support  design  assurance 
during  FSD.  The  collection  of  data  about  failures  experienced  by  FSD  items  forms  the  basis  of  the 
design  assurance  activities.  The  failure  data  are  collected,  collated,  and  summarized.  The  data  are 
collectively  analyzed  and  evaluated  to  detect  and  isolate  real  or  potential  reliability  problems 
Identified  problems  are  actively  monitored  and  tracked  until  they  are  resolved  They  are  summarized 
in  reliability  failure  summary  and  analysis  reports. 

4.5  PACKAGING  DESIGN 

Physical  design  of  the  LRU  often  begins  during  its  preliminary  design  and  continues  throughout  the 
FSD  phase  (Figure  20)  The  design  effort  is  based  on  a  system  packaging  concept  developed  during 
systems  engineering  and  the  detailed  circuit  design  data  developed  in  the  detailed  circuit  design  task. 
Packaging  design  consists  of  two  major  tasks,  mechanical  hardware  design  and  electronics 
packaging.  Mechanical  hardware  design  (Figure  20)  includes  designs  of  (1)  system  hardware, 
envelope,  panels,  racks,  etc.;  (2)  LRU  hardware,  envelope,  board  guides,  handles,  etc.;  (3)  board 
hardware,  size,  shape,  extractors,  stiffeners,  etc.;  and  (4)  component  hardware,  heat  sinks,  special 
mounting  fixtures,  special  packages,  etc  Much  of  the  mechanical  hardware  design,  such  as  the 
design  handles,  does  not  depend  on  the  circuit  characteristics  and  is  normally  accomplished  in 
parallel  with  the  detailed  circuit  design  effort.  The  design  of  the  electronics  packaging  involves  (1) 
partitioning  and  allocation  of  system,  LRU,  board,  and  component  electronics  (magnetics,  hybrids, 
ASICs);  (2)  cabling  design  of  system  and  LRUs;  and  (3)  board  and  component  wiring  (magnetics, 
hybrids,  ASICs). 

The  physical  design  of  the  hardware  and  electronics  (Figure  21)  is  based  on  the  results  of  extensive 
trade  studies  and  an  analysis  of  packaging  alternatives.  The  packaging  design  definition  includes  (1) 
size,  weight,  hardware,  and  interfaces  for  the  system  and  the  LRU;  (2)  the  number  of  boards,  board 
locations,  component  placements,  critical  circuits,  and  requirements;  (3)  nuclear  hardness  and 
survivability  requirements;  (4)  a  detailed  parts  and  modules  list  and  descriptions;  and  (5)  the  power 
requirements  of  the  system,  LRU,  and  boards. 
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Figure  20.  Packaging  Design 
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Note:  Feedback  loops  not  shown 
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Figure  21.  Detailed  Packaging  Design 
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*  environmental  control,  producibilitv,  durability,  reliability,  maintainability,  cost,  and  schedule 

requirements.  Section  5.0  provides  additional  details  on  some  of  the  key  parameter  and  attribute 
t  trades. 


4.5.2  Detailed  Packaging  Design 

The  tasks  involved  in  detailed  packaging  design  are  thermal  control  system  design,  packaging  design 
of  the  board  electronics,  and  design  and  packaging  of  boards. 


►  Thermal  Control  System  Design.  The  design  of  the  LRU’s  thermal  control  system  is  initiated 

f  during  systems  engineering  and  completed  during  detailed  design.  Generally  the  design  evolves  in 

parallel  with  the  mechanical  and  detailed  circuit  design  of  the  LRU  based  on  allocated  values  for 
cooling  flow,  pressure,  and  temperature.  The  baseline  system  concept  considered  during  FSD  usually 
includes  a  cooling  system  concept  definition,  as  well  as  a  concept  for  the  LRU’s  cooling  system 
interface.  However,  it  is  not  unusual  for  alternative  concepts  to  be  considered  during  FSD.  especially 
if  design  difficulties  are  encountered  with  the  baseline  concept  or  overall  cooling  requirements 
I  change  so  much  that  the  baseline  concept  is  no  longer  valid.  For  this  reason,  the  cooling  allocation  is 

k  tracked  as  the  design  progresses  to  enable  the  therma1  design  to  adapt  to  changes  in  the  system 

i  cooling  requirements. 

(  The  responsibility  for  the  design  of  the  thermal  control  system  is  shared  between  a  thermal  control 

system  designer  (a  packaging  designer)  and  a  systems  engineer.  The  dividing  line  between  their 
responsibilities  usually  occurs  at  the  envelope  enclosing  the  LRU  The  packaging  designer  is  usually 
responsible  for  selecting  the  thermal  management  technique  within  this  enclosure. 


Among  the  more  popular  thermal  control  techniques  for  avionics  systems  are  (l)a  cold  wall 
technique  in  which  the  coolant  is  circulated  through  the  walls  of  the  enclosure  and  heat  is  conducted 
from  each  printed  wiring  board  (PWB)  via  embedded  heat  conductive  strips  and  (2)  the  circulation  of 
coolant  (air)  directly  over  each  PWB  This  later  technique,  however,  has  an  inherent  problem  of 
contaminating  the  electronics  with  airborne  particulate  matter  as  well  as  liquid  condensate  For 
space-borne  applications,  the  enclosure  envelope  is  much  more  restrictive  than  for  airborne 
applications,  and  the  enclosure  design  must  be  integrated  into  the  vehicle’s  structure.  The  low 
temperature  and  the  absence  of  atmosphere  in  space  dictate  the  consideration  and  use  of  radiant 
cooling,  either  directly  or  indirectly 


Packaging  Design  of  the  Board  Electronics.  Packaging  the  board  electronics  involves 
partitioning  the  LRU  electronics  into  boards,  defining  the  packaging  constraints,  and  designing  the 
printed  wiring,  multiwire,  stitchwire,  or  wirewrap  boards  (Figure  22).  Inputs  to  this  process  are  the 
board  hardware  requirements,  the  inital  LRU  partitioning,  and  the  circuit  diagrams. 


Partitioning  the  LRU  electronics  into  circuit  boards  involves  the  tradeoffs  noted  in  Section  4.5  1  (see 
Section  5.0  for  additional  details).  Packaging  Design  often  assists  Detailed  Circuit  Design  (Figure  20) 
in  allocating  and  defining  the  board  partitioning  by  function. 

Packaging  constraints  are  derived  from  the  circuit  design  constraints  Constraints  are  associated 
with  decoupling  capacitors,  path  and  wire  thickness,  path  and  wire  sparing,  access,  component 
placement,  test  points,  grounding,  and  component  types  and  packages 

The  boards  are  designed  from  the  partitioned  electronics,  the  packaging  constraints,  and  the  board 
hardware  design.  Whether  the  design  is  a  PWB  or  a  multiwire,  stitchwire,  or  wirewrap  board  depends 
on  contractual  requirements.  Most  applications  dictate  the  use  of  PWBs  for  avionics  Multiwire, 
stitchwire,  and  wirewrap  boards  are  used  mainly  for  ground  equipment  and  breadboarding 
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Design  and  Packaging  of  Boards.  For  the  most  part,  the  design  process  How  is  similar  for  PWBs 
and  multiwire,  stitchwire,  and  wirewrap  boards  (Figure  23),  but  the  deliverables  of  each  task  are 
different  The  following  paragraphs  discuss  the  board  design  process  flow  in  general,  noting  only 
significant  differences  among  the  board  design  tasks. 

With  schematics  of  a  partitioned  board’s  circuit  and  the  board  and  component  geometric  libraries  as 
inputs,  the  components  are  placed  on  the  board  and  the  component  connections  are  routed  and  wired, 
taking  into  account  the  packaging  board  constraints  and  analyses  Since  component  placement 
directly  affects  the  board’s  thermal  properties,  the  thermal  constraints  may  dictate  a  component 
placement  or  density  less  than  that  desired  or  require  certain  routes  and  wires  to  be  larger  than 
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standard  or,  in  some  cases,  separated  or  shielded  Such  considerations  require  a  close  cooperation 
between  the  circuit  designer  and  board  package  designer 

Except  in  a  few  instances,  component  placement  and  routing  of  avionics  boards  is  performed 
manually.  The  experience  of  the  Boeing  packaging  designers  is  that  the  automatic  placement  and 
routing  tools  on  the  market  cannot  adequately  address  the  complexity  of  the  boards  typically 
designed  for  military  applications 
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Once  component  placement  and  routing  or  wiring  are  complete,  a  fabrication  dataset  that  defines  the 
geometry  of  the  board  layout  and  routing  is  prepared.  For  PWBs,  masks  used  to  etch  the  conductor 
patterns  on  the  board  are  also  generated.  Numerical  control  (NC)  data  are  generated  and  used  to 
control  automated  manufacturing  equipment  that  drills  board  holes  and  mills  the  board  outline.  For 
multiwire,  stitchwire,  and  wirewrap  boards,  the  NC  data  also  control  the  equipment  that  wires  the 
boards.  Other  board  design  outputs  are  assembly  and  fabrication  drawings.  The  stitchwire  and 
wirewrap  board  design  process  also  generates  wire  books  and  shop  lists.  These  outputs  are  all 
released  to  the  engineering  release  unit  by  the  program. 

4.5.3  Packaging  Analysis 

As  the  packaged  design  evolves,  it  is  analyzed  for  stress  and  vibration,  weight,  mass  properties,  and 
thermal  characteristics.  Detailed  analyses  generally  begin  at  the  component  level  and  eventually 
include  more  of  the  design  (board,  LRU)  until  the  critical  parts  of  the  system  are  analyzed  Often  the 
analyses  focus  on  a  particular  concern  identified  by  a  packaging  design  trade  study. 

The  stress  and  vibration  analysis  includes  nonoperating  and  operating  environments.  Nonoperating- 
environment  analysis  items  are  static  (constant)  acceleration,  pressure,  random  vibration,  and  bench 
handling  shock.  Operating-environment  analysis  items  are  static  acceleration,  pressure,  random 
vibration,  and  mission  shock  (missile  ejection,  flight  buffeting).  Stress  and  vibration  analysis  is 
conducted  using  computer-aided  finite  element  programs  to  perform  modal,  transmissibility,  stress, 
and  deflection  analyses.  Other  analytic  techniques  are  manual  calculations  that  use  standard  stress 
and  strain  relations  and  material  properties  extracted  from  design  manuals.  Some  of  the  analyses 
may  require  tests  using  physical  prototypes. 

The  thermal  analysis  includes  steady  state,  transient,  and  worst  case  analyses  at  the  system,  LRl'. 
board,  and  component  levels.  Computer-aided  finite  element  programs  are  normally  used  to  pi  ovide 
the  thermal  data  needed  o  assess  the  unit  s  conduction,  convection,  and  radiation  thermal  flow 
effectiveness.  Other  analysis  techniques  are  manual  calculations  using  standard  thermal  relations 
and  material  properties  from  design  manuals  Thermal  optimization  and  trade  studies  are  performed 
if  schedule  and  budget  allow. 


4.6  MANUFACTURING  DKSIGN 

Manufacturing  decisions  often  have  unanticipated  effects  on  the  characteristics  of  an  electronic 
circuit.  For  example,  the  manufacturing  process  used  to  solder  components  can  affect  the  reliability 
of  a  circuit  if  quality  control  of  the  soldering  process  cannot  be  maintained  For  this  and  other 
reasons,  detailed  producibility  and  manufacturing  test  reviews  are  often  conducted  by  the 
Manufacturing  Engineering  organization  within  Boeing  i  Figure  24)  The  purpose  of  these  reviews  is 
twofold:  ( 1 )  determining  whether  changes  to  the  design  are  warranted  to  address  producibility  and 
testability  concerns  and  (2)  ensuring  that  manufacturing  decisions  are  consistent  with  the  objectives 
and  requirements  of  the  item  being  manufactured. 

Although  Manufacturing’s  emphasis  during  these  reviews  is  on  cost  and  schedule  issues,  quality 
control  issues  associated  with  a  particular  design  are  also  evaluated.  Design  changes  may  be 
proposed  to  either  the  electronics  (e  g.,  circuit  elements,  circuit  boards)  or  the  mechanical  design  of 
the  LRU  (eg.,  cabinets,  mounting  brackets)  if  warranted  Although  it  seldom  happens,  significant 
design  changes  or  a  redesign  may  be  recommended  if  Manufacturing  believes  the  deficiencies  are 
severe  enough.  Except  where  changes  are  needed  for  safety  or  airworthiness  or  to  address  design 
deficiencies  that  prevent  the  unit  from  being  manufactured,  all  proposed  changes  must  be  justified  on 
a  cost  basis. 
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During  this  period.  Manufacturing  also  performs  extensive  producibility  trade  studies  to  determine 
the  most  cost-effective  method  of  producing  the  design  Again,  changes  to  the  design  may  be  proposed 
to  improve  the  manufacturing  process  (eg.,  enable  the  use  of  automated  equipment)  if  the  change  can 
be  justified  on  a  cost  basis.  Component  changes  are  typically  suggested  if  an  equivalent  part  exists 
that  costs  less,  enables  the  use  of  automated  assembly  equipment,  or  is  more  available.  Changes  to 
the  placement  of  components  or  boards  are  proposed  if  the  existing  placement  prevents  assembly  or 
manufacturing  test  operations. 

Although  Manufacturing  Design  conducts  the  analysis  and  recommends  changes  to  the  design,  the 
changes  must  be  implemented  by  either  Detailed  Circuit  Design  or  Packaging  Design.  The 
producibility  review  is  an  established  and  formal  procedure  within  Boeing;  a  review  of  testability  by 
the  Manufacturing  organization  is  not. 

As  noted,  Manufacturing  can  only  suggest  changes,  not  require  them.  This  appears  to  be  partially  the 
result  of  some  reluctance  on  the  part  of  the  circuit  designers  and  packaging  designers  to  incorporate 
features  in  the  design  that  affect  producibility  or  facilitate  the  manufacturing  test  processes.  In 
practice,  operational  and  performance  issues  always  take  precedence  over  any  factors  arising  from 
producibility  or  manufacturing  test  concerns. 

4.6.1  Producibility  Review  and  Trade  Studies 

Using  an  internally  developed  set  of  producibility  guidelines,  Manufacturing  Design  reviews  the 
packaging  description  and  part  lists  developed  by  Packaging  Design.  The  results  of  this  review  are 
provided  to  the  detailed  circuit  design  process,  the  detailed  packaging  design  process,  and  logistics 
analysis  ( if  affected)  in  an  iterative  fashion  until  the  producibility  concerns  are  resolved. 
Manufacturing  Engineering  reviews  the  design  mainly  to  reduce  production  costs,  develop 
manufacturing  schedules,  verify  producibility,  and  verify  that  adequate  quality  control  capabilities 
exist.  Changes  that  affect  reliability,  maintainability,  or  testability  may  be  proposed,  however.  For 
example,  assembly  methods  (i.e.,  hand  versus  automated  soldering  and  hardware  mounting), 
component  terminations  (sockets  versus  wire  terminations),  tolerances,  process  methods  (copper 
etching,  encapsulation,  etc.)  can  affect  reliability  and  maintainability  (accessibility,  test  equipment, 
test  procedures) 

Manufacturing’s  primary  concerns  in  the  producibility  review  and  trade  studies  are  ensuring  that 
( 1 )  the  components  called  out  in  the  engineering  drawings  are  compatible  with  automated 
installation  equipment  and  practices  (eg.,  axial-leaded  versus  edge-leaded  capacitors,  sufficient 
access  for  automated  equipment),  (2)  the  components  are  readily  available  (e  g  .  off-the-shelf 
components,  multiple  vendors,  no  schedule  impacts),  and  (3)  the  assembly  process  is  compatible  with 
current  manufacturing  capabilities  (e  g  ,  component  quality  and  other  tolerances  are  not  excessively 
tight). 

4.6.2  Manufacturing  Test  Review  and  Trade  Studies 

Manufacturing  Engineering  also  reviews  the  detailed  circuit  design  from  Detailed  Circuit  Design  and 
the  packaging  description  and  parts  list  from  Detailed  Packaging  Design  for  manufacturing  test 
capabilities  (Figure  24)  This  process  is  less  formal  than  the  producibility  review  and  is  initiated  at 
the  discretion  of  Detailed  Circuit  Design  management. 

There  are  differences  in  the  testability  requirements  needed  to  support  manufacturing  and 
operational  (in-the-field)  testing.  Manufacturing  emphasizes  a  unit’s  functionality  for  quality  control 
Operational  testing  is  biased  toward  rapid  fault  isolation.  Since  designing  the  unit  for  testability  is 
usually  the  responsibility  of  the  LRU  circuit  designers,  and  the  design  of  the  test  equipment  is  the 
responsibility  of  an  organization  that  designs  special  test  equipment  (STE),  inconsistencies  in  the 
testability  approaches  often  occur.  As  noted  previously,  there  is  some  reluctance  on  the  part  of  the 
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circuit  design  and  packaging  communities  to  incorporate  test  capabilities  that  address  only 
manufacturing  test  and  quality  control  issues 

4.6.3  Detailed  Manufacturing  Design 

A  key  deliverable  of  the  detailed  manufacturing  design  task  is  a  comprehensive  manufacturing  plan 
that  details  how  and  where  hardware  items  will  be  manufactured.  It  defines  the  use  of  automation, 
specific  manufacturing  processes,  required  skills,  make  or  buy  decisions,  quality  assurance 
requirements,  and  other  capabilities  required  to  meet  contract  specifications.  An  overall  detailed 
manufacturing  schedule  for  the  program  is  also  developed  at  this  time  in  negotiations  with  the 
Circuit  Design  and  Packaging  Design  organizations.  Baseline  manufacturing,  engineering,  and 
material  flows  are  developed  from  hardware  descriptions  developed  in  Detailed  Circuit  Design  and 
Detailed  Packaging  Design.  The  plan  is  used  by  all  the  Manufacturing  build  and  test  operations  to 
describe  how  all  manufacturing  operations  will  be  managed  to  build  and  test  the  product. 

Resource  (e.g.,  skills,  equipment,  material,  facilities)  and  cost  (e  g.,  labor,  equipment,  materials) 
inputs  to  the  plan  come  from  all  Manufacturing  operations.  System-level  requirements,  management 
guidelines,  and  the  packaging  description  and  part  lists  from  the  Packaging  Design  organization  are 
used  by  the  Detailed  Manufacturing  Design  organization  to  develop  the  plan. 

Changes  to  either  the  electronics  or  the  hardware  may  be  recommended  as  a  result  of  the 
manufacturing  process  or  scheduling  conflicts  Chronologically,  these  changes  are  recommended 
after  those  resulting  from  the  producibility  and  testability  review,  since  those  tasks  are  often 
completed  before  the  detailed  plan  is  developed  and  the  problems  are  recognized  Typical  changes  are 
caused  by  the  unavailability  ofqualified  componentsor  manufacturing  resources. 

Detailed  Manufacturing  Plan.  To  support  the  development  of  a  plan  for  the  manufacturing 
process,  trade  studies  are  conducted  to  assess  the  manufacturing  alternatives.  These  studies 
typically  consider: 

a.  Manufacturing  equipment  and  facility  requirements  , total  workforce,  skills,  capital  equipment, 
space,  and  shop  load). 

b  Tooling  resources  and  costs. 

c  Factory  resources  and  costs. 

d.  Component  and  material  requirements  and  costs. 

e  Qualification  of  the  manufacturing  process. 

Unit  Fabrication  and  Verification.  Once  the  designed  unit  is  actually  fabricated,  no  major 
changes  can  be  made  without  a  redesign  As  a  result,  only  miner  tuning  of  the  unit’s  packaging  or 
fabrication  process  is  allowed 

Changes  to  the  design  or  the  fabrication  process  are  made  according  to  the  same  criteria  as  the 
producibility  and  testability  review.  Where  accepted,  the  changes  result  in  revisions  to  the  detailed 
design  definition  and/or  the  manufacturing  plan. 

Using  the  developed  test  software,  procedures,  and  equipment,  the  FSD  "as-built”  unit  is  evaluated  to 
ensure  that  it  meets  the  design  drawing  requirements  and  contractual  requirements.  Process 


57 


verification  tests  to  verify  processes,  functional  tests  to  verify  operation,  and  qualification  tests  to 
verify  the  "-ility”  requirements  are  performed  on  the  as-built  unit. 

Manufacture  Production  Unit.  Once  the  FSD  unit  is  qualified,  the  manufacturing  dataset  and 
plans  become  the  definition  and  manufacturing  process  for  the  production  (deliverable)  units.  At  this 
point,  changes  cannot  be  effected  without  a  large  impact  on  the  program’s  schedule  and  cost.  As  a 
consequence,  changes  are  considered  only  if  they  are  required  by  severe  deficiencies  in  the  design. 

4.7  LOGISTICS  SUPPORT  ANALYSES 

During  the  systems  engineering  process  (Section  3.0),  the  logistics  support  analyses  (LSA)  defined  in 
MIL-STD-1388  (-1A  and  -2A)  are  initiated  to  aid  in  the  development  of  supportability  design 
requirements  and  guidelines,  provide  inputs  to  the  life  cycle  cost  analysis,  and  identify 
supportability  drivers  (design  factors  dictating  the  supportability  of  a  system).  These  analyses  are 
continued  during  detailed  design  primarily  to  support  the  development  of  technical  data  (eg., 
technical  manuals),  detailed  maintenance  and  spares  requirements,  and  supporting  equipment  (e  g., 
special  test  equipment)  needed  to  field  the  system  of  which  the  LRU  is  a  part.  The  analyses  do, 
however,  provide  a  basis  for  assessing  the  supportability  of  the  end  item’s  design. 

Ideally,  the  detailed  design  of  the  LRU  is  monitored  as  it  evolves  and  these  analyses  are  continually- 
performed  to  ensure  that  the  supportability  costs  are  being  minimized.  This  is  not  always  possible, 
however,  due  to  schedule,  manning,  or  budget  limitations.  In  many  cases,  supportability  is  assessed 
in  depth  only  after  the  completion  of  the  detailed  packaging  design  task  (Figure  25),  often  just  prior  to 
the  PDR.  At  this  point  a  large  portion  of  the  LRU  design  has  been  finalized  and  changes  to  the  design 
are  expensive  As  a  consequence,  recommended  design  changes  stemming  from  these  analyses  are 
incorporated  into  the  LRU’s  design  only  if  a  severe  deficiency  is  identified. 

Although  all  15  LSA  tasks  are  performed  during  detailed  design,  their  emphasis  shifts  from  trying  to 
influence  the  design  to  defining  how  the  system  being  designed  will  be  supported.  Three  tasks 
(repair-level  analysis,  supportability  analysis,  and  logistics  support  analysis  record)  are  considered  to 
consume  a  majority  of  the  resources  allocated  to  the  LSA.  Figure  26  shows  the  relationship  between 
these  tasks.  Figure  27  shows  the  relationship  between  availability  and  the  key  reliability, 
maintainability,  and  supportability  parameters. 

Repair-level  analysis  provides  an  economic  basis  for  determining  whether  electronic  assemblies  le  g  , 
LRU,  SRU)  that  have  failed  in  the  field  should  be  discarded,  repaired  at  an  intermediate-level 
facility,  or  repaired  at  a  depot  level  facility  Among  the  factors  this  analysis  considers  are  the  unit 
cost  of  the  LRU  or  SRU,  the  average  number  of  operating  hours  per  month,  the  number  of  man-hours 
required  to  remove  and  replace  the  unit,  support  equipment  factors,  and  mean  lime  between 
maintenance.  Although  this  analysis  is  performed  during  systems  engineering  to  influence  the 
design,  in  detailed  design  its  primary  purpose  is  to  determine  the  repair  levels  of  the  system  specified 
in  the  configuration  item  specification 

Detailed  system  maintenance  and  support  plans  are  normally  developed  during  the  late 
demonstration  and  validation  or  early  FSD  phase  of  design  as  part  of  the  supportability  task  To 
support  this  effort,  the  LSA  study  is  updated  to  provide  an  improved  basis  for  all  system  utilization 
models.  During  this  study,  the  mission  profile,  storage  requirements,  maintenance  philosophies,  and 
life  cycle  costs  are  reviewed  to  determine  how  any  changes  in  these  parameters  have  affected 
supportability.  Failure  rate  data,  based  on  a  MIL-STD-217  analysis,  are  used  to  update  the 
organizational  level  maintenance  predictions  (e  g  ,  maintenance  man-hours). 

The  LSA  data  are  documented  in  the  logistics  support  analysis  record  (LSAR).  The  LSAR  forms  the 
basis  for  most  support  activities  during  the  production  and  postproduction  phases.  Included  in  the 
LSAR  is  information  to  support  technical  manual  development,  training  course  identification  and 
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Assess  design 
baseline 


development,  training  and  support  equipment  identification,  and  analyses  such  as  repair-level 
analyses  and  maintenance  manning  plans. 


Although  development  of  the  LSAR  begins  as  early  as  possible  during  concept  exploration,  the  major 
part  of  this  task  is  performed  only  when  the  system  design  is  fairly  well  established.  The  data  in  the 
LSARs  relate  to  operational  and  maintenance  requirements,  mission  profiles,  operating 
environments,  system  specification  and  requirements  data,  reliability  and  maintainability  data, 
FMEA,  failure  criticality  data,  maintenance  task  summaries  and  predictions,  personnel  and  support 
equipment  requirements,  training  and  technical  data  requirements,  test  procedures,  facilities 
requirements  and  utilization  plans,  personnel  skill  levels,  support  items  (tools,  chairs,  testers,  etc  ), 
transportability  information,  and  handling  instructions. 

Within  Boeing,  an  LSAR  computer  program  modeled  on  the  Automated  Logistics  Support  Analysis 
(ALSA)  system  is  used  to  automate  parts  of  the  M1L-STD-1388-2A  LSAR. 


Figure  26.  Logistics 
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5.0  DESIGN  CONSIDERATIONS 


It  is  easy  to  assume  that  the  design  of  an  electronic  assembly  is  limited  to  the  definition  of  the  circuit. 
In  fact,  there  are  extensive  physical  considerations  involved  in  such  a  design.  Although  these  are 
largely  in  the  domain  of  packaging,  they  influence  the  design  from  the  beginning.  Examples  of  some 
of  these  factors  are  noted  in  the  following  sections. 

5.1  COMPONENT  CONSIDERATIONS 

Component  Technology.  Technology  alternatives  (e  g  ,  CMOS,  ECL,  TTL,  analog,  hybrid)  differ  in 
design  characteristics  such  as  cost,  power  consumption,  speed,  heat  generation,  size  (area  and  height), 
and  thermal  sensitivity.  For  avionics  applications,  these  and  other  factors,  such  as  electromagnetic 
interference  (EMI),  electromagnetic  pulse  (EMP),  and  radiation  hardness,  must  be  considered  to 
ensure  that  the  most  appropriate  technology  is  selected.  For  example,  CMOS  has  low  power 
requirements,  a  desirable  characteristic  for  avionics  applications,  but  is  very  susceptible  to  static 
electricity.  If  it  is  to  be  used,  all  interfaces  to  the  CMOS  circuitry  must  be  buffered  by  embedding  it 
within  another  technology  or  adding  additional  circuitry  to  filter  all  external  signals.  TTL  is  faster 
and  consumes  less  area  than  CMOS,  but  consumes  more  power. 

Component  Package  Types.  For  a  given  technology,  several  packaging  and  mounting  options  are 
typically  available,  such  as  dual  inline  packaging,  flat  pack,  chip  carrier,  and  surface  mount  (SMT). 

In  addition  to  the  obvious  considerations  of  cost  and  area  consumption,  reliability  and 
maintainability  are  also  factors.  DIP  packages  are  preferred  because  of  lower  cost  and  ease  of 
installation  (autoinsertion),  and  they  are  generally  more  available  However,  height  and  lateral 
space  requirements  (volume)  may  require  the  use  of  SMT.  This  in  turn  effectively  eliminates  the 
possibility  of  component  replacement  as  a  repair  option  and  increases  fabrication  costs  In  addition, 
if  testability  is  a  consideration,  test  pads  should  be  used  to  facilitate  autotest  or  technician  access 

Component  Placement  Boards  may  be  designed  to  have  components  on  one  side  or  both  A 
minimum  component  clearance  is  required  for  use  of  autoinsertion  and  component  level  autotest 
equipment  A  board  real-estate  check  may  show  that  the  board  density  is  too  high  for  placement, 
routing,  producibility,  cooling,  or  testability  requirements  if  only  one  side  is  used  Mounting 
components  on  both  sides  may  be  preferred  in  this  case  because  more  components  can  be  placed 
within  the  same  volume,  but  such  boards  are  harder  to  design  and  manufacture  Mounting 
components  on  both  sides  of  the  board  may  require  special  manufacturing  test  rigs  to  support 
manufacturing  quality  assurance  testing 

The  different  electronic  components  installed  on  a  printed  wiring  board  (PWBl  possess  different 
thermal  reliability  characteristics  and  a  placement  configuration  for  the  components  must  be  found 
that  minimizes  the  failure  rate  of  the  PWB  assembly  and  considers  the  electrical  characteristics  of 
the  components  Board  flexing  also  complicates  component  placement  and  routing  since  components 
should  not  be  placed  over  board  flex  points  and  cannot  be  placed  over  ribs  or  braces. 

Connectors.  Connectors  are  one  of  the  worst  reliability  problems  Special  connectors,  special 
handling  for  disassembly,  or  special  installation  are  often  required. 

5.2  BOARD  CONSIDERATIONS 

Board  Material.  If  at  all  possible,  it  is  preferred  to  build  the  circuit  boards  of  lightweight  material 
This  may  not  be  feasible,  however,  because  the  extra  bracing  or  increased  thickness  required  to 
minimize  board  flexing  and  vibration  may  consume  more  volume  than  is  available 
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Board  Types.  Special  board  types  such  as  those  having  metal  cores  may  be  required  to  dissipate 
heat.  These  boards  typically  impact  cost,  producibility,  and  other  issues  and,  therefore,  are  avoided  if 
at  all  possible. 

Board  Size  Key  concerns  are  whether  the  board  size  is  sufficient  to  mount  all  the  components 
allocated  to  it,  whether  the  board  size  can  be  handled  by  all  manufacturing  processes,  how  many 
layers  are  required,  and  whether  the  line  replaceable  unit  (LRU)  enclosure  requires  the  components 
to  lie  flat. 

Board  Structure  Shock  and  vibration  requirements  often  require  that  the  circuit  board  be  ribbed, 
braced,  or  otherwise  protected.  Such  features  affect  volume  consumption  and  component  placement. 
The  unit  must  be  able  to  withstand  constant  acceleration,  pressure,  random  vibration,  bench 
handling  shock,  and  mission  shock. 

Board  Environmental  Control.  Salt  spray,  acid,  water,  and  humidity  may  cause  circuit 
degradation  and  loss  of  signal  path  continuity  due  to  corrosion  or  fungus.  The  board  may  need  to  be 
sealed  (eg.,  with  conformal  coating)  or  made  of  corrosion-resistant  materials  to  improve  reliability. 
This  protection  drives  up  fabrication  cost,  since  a  sealed  unit  is  expensive  to  build,  and  maintenance 
cost,  since  access  to  the  components  is  restricted,  but  it  may  be  required  to  meet  the  reliability 
specification. 

5.3  LRU  CONSIDERATIONS 

LRU  Size  and  Shape.  The  LRU  must  be  large  enough  to  handle  all  the  parts.  For  example,  the 
board  components  may  be  too  tall  for  the  board  to  fit  inside  the  LRU  envelope.  Laying  the 
components  fiat  takes  up  more  space  and  may  affect  thermal  requirements.  Low-profile  components 
may  solve  this  problem  but  may  be  less  reliable 

A  special  shape  may  be  required.  Special  shapes  dictate  material  type  and  typically  drive  up 
fabrication  costs.  Unusual  shapes  may  also  require  special  support  equipment 

LRU  Weight,  Center  of  Gravity,  and  Moment  of  Inertia  The  weight  of  the  LRU  is  a  function  of 
the  weight  of  the  components,  boards,  connectors,  and  LRU  enclosure.  The  weight,  shape,  size,  or 
structural  characteristics  of  the  design  may  result  in  an  LRU  greater  than  the  desired  maximum 
weight  of  40  lb  or  in  center-of  gravity  problems.  Ballast  (additional  weight)  may  be  required  to 
balance  the  LRU  for  technician  handling 

LRU  Structure.  The  LRU  must  be  designed  to  withstand  a  variety  of  shocks  (handling  and  mission), 
vibration,  pressure  differentials,  and  acceleration  requirements.  The  mechanical  design  of  the  LRU 
may  need  to  incorporate  ribs,  bracing,  or  other  structural  features 

LRU  Environmental  Control.  Environmental  concernsother  than  heat  dissipation  (e  g  ,  dust  and 
air  quality),  may  require  sealing  of  the  LRU  or  the  incorporation  of  filters. 

Latitude  in  the  design  of  thermal  management  for  avionics  equipment  is  more  dependent  on  the  air 
vehicle  and  the  inherent  thermal  environment  than  on  the  avionics  equipment  A  common  scenario 
is  the  updating  of  avionics  equipment  on  an  existing  weapon  system  For  these  cases,  the  available 
cooling  capacity  has  a  firm  limit,  and  the  equipment  must  be  designed  to  operate  within  that  limit. 
Depending  upon  the  cooling  requirements  of  individual  PWBs,  they  may  be  arranged  in  series,  in 
parallel,  or  in  any  combination  thereof  relative  to  the  coolant  flow  within  the  enclosure. 

Optimization  involves  selection  of  the  coolant  distribution  patterns  and  flow  rates  that  result  in  a 
minimum  failure  rate  for  the  total  enclosure.  Design  constraints  are  the  allowable  coolant-pressure 
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drop  across  the  enclosure,  allocated  coolant  flow  rate,  and  maximum  allowable  component 
temperatures. 

5.4  COUPLING  OF  CONSIDERATIONS 

Packaging  is  a  primary  driver  in  the  reliability,  maintainability,  and  supportability  of  a  system  and 
is  inherently  part  of  the  later  phases  of  the  detailed  design  process.  Component  packaging  decisions 
affect  board-level  packaging,  which  in  turn  affects  the  design  of  the  LRU  and  the  overall  compliance 
of  the  system  with  the  reliability,  maintainability,  and  supportability  (RM&S)  requirements.  For 
example,  a  detailed  designer  may  select  ECL  technology  for  improved  circuit  performance.  This 
decision  has  tradeoffs  in  area  consumption  and  component  packaging  technology  (e  g.,  SMT 
components  may  be  precluded!.  If  other  board-level  designers  need  to  use  SMT  components  to  meet 
their  thermal  constraints  (SMT  components  dissipate  heat  more  effectively),  system  maintainability 
and  supportability  will  be  compromised  due  to  multiple  mounting  types.  ECL  technology  also 
consumes  more  power,  which  in  turn  generates  more  heat.  The  power  and  thermal  tradeoffs  may  be 
system-level  issues  if  the  allocations  to  the  lower  levels  did  not  include  sufficient  reserves. 

This  tight  coupling  between  detailed  design,  packaging,  RM&S  characteristics,  and  system-level 
requirements  necessitates  a  continual  feedback  throughout  all  levels  of  the  system  design.  Without 
improved  knowledge  of  the  current  state  of  the  entire  system  design,  design  engineers  may  select 
suboptimal  strategies  when  dealing  with  functional  design  or  performance  problems. 

Specific  classes  of  these  design  considerations  are  evaluated  by  specialized  engineering  disciplines 
This  tends  to  impede  communication  and  prevent  the  timely  propagation  throughout  the  design 
community  of  the  design  constraints  resulting  from  each  design  decision 
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6.0  DESIGN  PROCESS  PROBLEMS 


As  the  systems  being  designed  have  grown  more  complex,  the  design  process  has  changed.  The 
process  and  schedules  require  the  ready  availability  of  expert  design  knowledge,  as  well  as  integrated 
supporting  computer  tools  and  data  management  systems. 

This  study  has  shown  that  - 

a.  Most  descriptions  of  the  design  process  contain  errors. 

b.  The  cultures  of  both  the  customer  and  the  contractor  influence  the  design  process. 

c.  The  design  process  and  its  supporting  computer-aided  engineering  (CAE)  tools  have  difficulties 
and  impediments  that  inhibit  the  development  of  optimal  designs. 

6.1  UNAVAILABILITY  OF  KNOWLEDGE 

As  the  complexity  of  electronic  systems  has  increased  in  response  to  competitive  pressures,  the 
processes  employed  in  their  design  and  manufacture  have  become  more  specialized  The  design  of  a 
"typical”  system  now  requires  specialized  knowledge  in  areas  such  as  functional  design,  application- 
specific  integrated  circuit  (ASIC)  design,  vibration,  routing,  automated  assembly,  testability,  and 
reliability  This  requirement  has  introduced  a  need  for  those  involved  in  the  design  effort  to  integrate 
the  diverse  knowledge  and  skills  of  a  number  of  disciplines.  Because  our  knowledge  of  how  emerging 
design  disciplines  should  interact  is  often  incomplete,  the  disciplines  are  not  always  effectively 
integrated  As  a  result,  systems  are  often  produced  that  are  less  than  optimal  or  that  fail  to  satisfy  all 
of  the  requirements  to  which  they  are  being  designed. 

The  knowledge  needed  by  designers  can  be  divided  into  four  areas:  design  principles,  design 
methodologies,  design  knowledge,  and  reference  data  These  areas,  representing  the  way  in  which 
the  designer  approaches  a  design  problem  and  the  resources  that  he  or  she  can  bring  to  bear,  are 
discussed  in  the  following  paragraphs 

Design  Principles.  The  principles  of  design  are  usually  described  as  abstract  concepts  such  as 
"design  for  testability.”  Although  each  discipline  employs  metrics,  such  as  fault-detection  coverage, 
and  design  rules,  such  as  "do  not  tie  resets  to  ground,”  they  seldom  encompass  the  concerns  of  other 
disciplines. 

The  design  rules,  principles,  and  techniques  that  designers  must  know  and  follow  in  each  of  these 
disciplines  are  documented  in  a  plethora  of  company  design  manuals,  military  standards,  program 
design  guidelines,  parts  manuals,  and  experience  databases.  Unfortunately,  the  availability  of  this 
information  does  not  guarantee  these  sources  are  reviewed  by  the  designers,  or  even  whether  or  not 
the  designers  known  that  they  exist.  As  a  consequence,  designers  seldom  have  an  in-depth 
knowledge  of  the  principles  and  rules  of  good  design  in  all  disciplines. 

Design  Methodologies.  Design  methodologies  are  the  methods  and  approaches  used  to  design 
systems  or  subsystems.  There  are  three  main  categories  of  methodology:  ( 1 )  synthesize;  (2)  simulate; 
and  (3)  test,  analyze,  and  fix  Any  of  these  methodologies  can  be  used  to  produce  good  designs  if  it  is 
used  correctly,  but  the  first  two  are  preferable  Currently,  designers  predominantly  use  a  "test, 
analyze,  and  fix”  method  and  few  CAE  tools,  relying  instead  on  breadboards  and  prototypes.  This 
method  involves  many  iterative  design  changes  and  takes  a  long  time  to  implement  correctly. 

Current  design  programs  do  not  allow  the  time  needed  to  optimize  designs  using  this  method.  The 
shortage  of  time  causes  the  designers  to  consider  only  the  principles  of  design  that  they  understand 
well;  they  do  not  readily  consider  those  such  as  testability  that  are  more  difficult  to  implement. 
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Design  Knowledge.  Many  designers  find  it  difficult  to  obtain  the  knowledge  necessary  to  optimize 
designs  for  considerations  other  than  functionality.  Much  of  that  knowledge  is  contained  in 
experience-based  databases  and  documents.  These  experience-based  data  could  be  accessed  but  are 
buried  among  formal  design  notes  and  documentation  and  not  listed  in  any  sort  of  easily  accessible 
index.  As  an  example,  in  order  to  use  three  of  the  major  experience  databases  available,  the  designer 
must  know  the  military  system  part  number.  The  knowledge  is  not  accessible  by  nomenclature  or 
through  the  engineer’s  workstation. 

Reference  Data.  Some  of  the  required  reference  data  on  components  and  design  elements  are  not 
readily  available.  The  current  sources  of  reference  data  are  widely  scattered.  The  most  common 
sources  are  manufacturers’  reference  and  data  books,  which  are  often  incomplete.  To  obtain  the 
required  data  on  a  particular  part,  several  separate  books  may  need  to  be  checked.  Parts  databases 
and  experience  analysis  databases  are  also  not  easily  available. 

Much  of  the  information  needed  by  designers  for  optimization  is  possessed  by  specialists.  The  time  of 
these  specialists  is  in  high  demand,  and  sometimes  they  are  not  available  to  provide  the  assistance 
needed  by  a  particular  project.  Present  systems  do  not  provide  an  effective  means  of  storing  the 
knowledge  of  these  experts  and  passing  it  on  to  other  designers. 

6.2  DESIGN  PROCESS 

In  general,  design  tasks  are  divided  among  several  distinct  groups  and  subgroups,  typically  by 
discipline  or  specialty  Each  group  is  made  up  of  individuals  who  have  developed  design  styles  that 
appear  to  work  This  results  in  distinct  breaks  in  the  design  process,  since  the  actual  design 
methodology  may  vary  significantly  between  groups.  In  addition,  the  knowledge  and  data  necessary 
for  creating  a  design  are  fragmented  among  the  various  groups.  Several  related  types  of  problems  are 
created  by  these  conditions 

When  design  descriptions  are  transmitted  between  groups,  only  an  "outline”  of  the  data  comes  across. 
Most  of  the  design  characteristics  and  metrics  stay  with  the  group  that  understands  the  relevance  of 
the  data  to  the  design  Knowledge  about  key  design  considerations  is  unavailable  for  use  by  other 
groups  For  instance,  the  formal  document  of  the  Detailed  Design  group  is  the  schematic,  which  can 
be  broken  down  into  a  netlist  and  a  parts  list.  Data  relating  to  electromagnetic  interference,  testing, 
and  layout  constraints,  for  example,  are  not  usually  specified  to  layout  and  packaging  organizations. 

Transmitting  the  data  also  causes  delays.  Some  delays  can  be  so  long  that  the  needed  information 
does  not  get  to  the  appropriate  individual  in  time  to  be  useful.  Communication  can  also  be  a  problem 
when  transferring  design  data  between  groups.  The  different  groups  may  use  different  tools  and  have 
to  re-enter  data,  or  they  may  require  data  in  another  form,  which  can  lead  to  delays  and  errors.  Just 
getting  the  answer  to  a  single  question  may  require  several  days. 

As  a  design  evolves  in  a  top-down  approach,  a  direct  relationship  in  terms  of  parameters  and  metrics 
between  the  hierarchical  levels  is  not  typically  generated.  The  formal  data  consist  only  of  block  and 
flow  diagrams  and  a  set  of  requirements  Modeling  and  analyses  rarely  cross  and  mix  the 
hierarchical  levels.  Checking  is  done  only  in  a  general  manner  to  ensure  that  a  lower  level 
representation  matches  a  higher  level  one.  Another  aspect  of  this  problem  is  that  there  are  few 
metrics  established  to  relate  multiple  levels  of  a  design  Many  characteristics  at  the  high  levels  lack 
meaningful  or  complete  metrics.  For  example,  few  metrics  exist  for  reliability  at  the  concept  level, 
and  no  general  method  exists  for  relating  reliability  characteristics  between  hierarchical  levels. 

Because  system-level  requirements  are  not  reflected  in  metrics  and  characteristics  that  relate  to  the 
lower  level  design  task,  detailed  designers  cannot  easily  determine  the  relative  importance  of  key 
characteristics  in  low-level  trade  studies  They  can  conduct  sensitivity  analyses  only  on  the  basis  of 
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their  requirements  and  trade  off  by  maximizing  or  minimizing  a  characteristic  such  as  reliability  or 
cost. 

Pieces  from  an  existing  design  are  seldom  used  for  two  key  reasons.  Design  knowledge  gained  from  a 
design  project  is  often  lost  once  the  design  is  complete.  Trade  study  data  and  key  elements  in  making 
design  decisions  are  not  captured.  Rough  comparisons  to  existing  designs  are  made,  but  a  large 
margin  for  error  exists.  Almost  all  existing  designs  require  some  modification  for  use  on  a  new 
project,  and  modification  is  difficult  without  the  original  design  data.  There  are  few  standard 
reusable  design  elements  and  interfaces. 

Trade  studies  performed  during  the  design  process  are  usually  informal  There  are  no  guidelines  to 
determine  the  areas  to  be  traded,  alternatives  to  be  traded,  or  how  detailed  the  study  needs  to  be. 

Once  the  study  has  been  performed,  there  is  no  process  for  capturing  the  data. 

Few  engineers  do  a  multilevel  optimizing  analysis.  No  accepted  standard  optimizing  analysis 
procedure  currently  exists.  In  addition,  some  of  the  data  needed  to  perform  the  optimization  are  often 
difficult  to  obtain.  To  be  maximally  useful,  such  a  technique  would  also  h  ■"n  to  support  optimization 
at  various  levels  of  abstraction  simultaneously. 

6.3  CULTURE 

The  major  problem  associated  with  culture  is  resistance  to  change.  Organizations  of  both  the 
customer  and  contractor  have  evolved  as  they  have  for  good  reasons. 

The  customer  and  the  contractor  have  built  organizations  to  cope  w;th  the  increasing  complexity  of 
weapons  systems  and  the  specialized  knowledge  necessary  to  understand  the  technical  details.  These 
organizations  consist  of  procurement  management  and  design  analysis  specialists. 

The  managers  of  both  the  customer  and  the  contractor  have  spent  their  careers  with  the  procurement 
and  design  systems  currently  in  place.  They  feel  that  little  change  is  necessary,  since  the  processes 
have  worked  in  the  past,  and  that  new  processes  or  procedures  may  make  things  worse  "Let  someone 
else  experiment"  seems  to  be  the  prevalent  attitude 

Contractors  have  spent  millions  of  dollars  developing  their  present  systems  They  have  evolved  as 
needs  have  forced  them  to  change  The  company’s  personnel  understand  the  way  the  company  does 
business.  Any  change  would  require  new  investment  and  increased  training  cost. 

The  customer  has  created  an  organization  of  specialists  to  monitor  system  development  and  the 
overall  procurement  process.  These  specialists  have  established  review  procedures  and  imposed 
contractual  needs  for  periodic  reviews  and  analysis  data  deliverables.  The  reviews  and  technical 
meetings  have  become  part  of  the  way  business  is  conducted.  The  contractors  have  built 
organizations  to  match  the  customer’s,  and  specialist  groups  have  been  formed  both  to  interface  with 
the  customer’s  specialists  and  to  perform  the  analyses  required  by  the  contract. 

Because  of  reluctance  to  change  this  process,  contractors  and  customers  have  insisted  on  adding 
checks  into  the  design  systems  to  analyze  and  verify  product  compliance  with  the  specification  These 
checks  are  similar  to  the  manufacturing  quality  control  procedure.  They  do  not  improve  the  product; 
they  just  verify  that  it  meets  minimum  standards. 

The  development  of  specialists  for  various  disciplines  such  as  reliability,  maintainability,  and 
functional  design  tends  to  create  barriers  between  the  members  of  the  product  development 
organization.  Such  groups  as  Reliability,  Maintainability,  and  Logistics  are  formed  separately  from 
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the  design  team.  This  separation  tends  to  promote  isolation  of  the  specialists  and  break  down 
communication. 

6.4  DESIGN  TOOLS 

At  present  there  is  no  integrated  computer-aided  design  or  computer-aided  engineering  (CAD/CAE) 
tool  that  addresses  all  phases  of  the  design  process  and  includes  even  the  most  important  of  the 
specialized  analyses.  There  are  very  few  tools  that  address  the  design  process  at  the  system  level. 
Those  that  are  available  are  passive  diagramming  tools  with  no  provision  for  capturing  and 
analyzing  the  relationships  between  portions  of  the  diagram.  As  a  result,  the  representation  they 
create  is  not  useful  as  input  to  an  analysis  tool,  nor  can  it  serve  as  a  starting  point  for  tools  addressing 
detailed  design. 

There  are  more  tools  available  to  support  detailed  electronic  circuit  design  However,  most  of  these 
tools  are  oriented  to  the  final  detailed  design;  they  provide  little  support  for  recording  more  abstract 
levels  of  the  design  or  for  refining  these  abstractions  into  detailed  circuits.  As  a  result,  the  tools  are 
used  more  as  drafting  and  documentation  aids  than  as  design  aids.  Thus,  the  actual  design  process  is 
largely  a  manual,  paper-and-pencil  activity  It  is  difficult  to  provide  useful  automated  assistance 
since  the  fundamental  process  is  not  occurring  in  an  automated  environment. 

Even  if  there  were  tools  supporting  each  phase  of  the  design  effort,  there  would  remain  a  need  for  an 
integrated  tool  that  could  analyze  designs  across  phases  Such  a  tool  is  necessary  to  provide 
automated  assistance  in  tracking  requirements  so  that  a  high-level  requirement  can  be  related  to  the 
aspects  of  the  design  that  satisfy  it,  and  the  design  requirements  that  constrain  the  design  of  a 
particular  element  can  be  identified  A  similar  level  of  integration  is  required  in  a  tool  to  verify  that 
a  design  at  one  level  is  consistent  with  the  more  abstract  specification  of  tne  same  design  at  a  higher 
level  Finally,  the  level  of  detail  is  not  consistent  across  an  entire  design.  The  description  of  familiar 
aspects  is  likely  to  be  left  at  an  abstract  level,  while  more  novel  portions  of  the  design  are  carried  to 
greater  detail  to  provide  greater  confidence  in  the  proposed  solutions.  Thus,  as  design  actually 
occurs,  only  a  ^ol  capable  of  representing  a  design  across  multiple  levels  of  abstraction  can  represent 
the  current  status  of  the  entire  design 

There  are  complex  tools  available  for  performing  some  of  the  specialized  analyses  supporting  the 
design  process.  These  tend  to  automate  current  approaches,  so  they  critique  a  design  after  it  has  been 
produced,  rather  than  provide  useful  assistance  in  creating  the  design.  They  also  tend  to  address  the 
most  analytical  parameters,  such  as  functionality,  timing,  and  heat  generation.  There  are  few  tools 
available  to  measure  less  analytical  parameters  such  as  the  reliability,  maintainability,  or  testability 
of  a  circuit 

Designers  are  usually  not  aware  of  the  foil  range  of  tools  available  to  them.  Even  if  the  designer  is 
aware  of  the  existence  of  a  tool,  he  or  she  requires  training  to  use  it  and  to  interpret  the  results  it 
provides  There  is  rarely  sufficient  budget  to  provide  training  in  the  use  of  tools,  and  even  less  budget 
to  keep  the  training  up  to  date  as  the  tools  evolve  or  are  replaced  with  newer,  more  powerful  tools. 
Inconsistent  user  interfaces  among  the  tools  make  it  difficult  to  retain  knowledge  of  how  to  use  tools 
that  are  used  infrequently.  Learning  and  using  one  tool  tends  to  interfere  with  the  retention  of 
training  about  how  to  use  another  tool 

Since  the  tools  are  not  integrated,  data  formats  are  usually  inconsistent  from  tool  to  tool.  Because  the 
design  is  being  produced  manually,  the  designer  must  seek  out  or  create  an  electronic  representation 
of  the  relevant  data  in  order  to  use  a  tool  In  all  but  the  most  fortunate  instances,  this  will  require 
reorganization  and  reformatting  of  existing  data  Frequently  manual  data  entry  is  required  as  well 
These  factors  reduce  the  utility  of  the  tools  and  feed  the  designer’s  natural  resistance  to  change,  so  the 
tools  often  sit  unused 
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Detailed  circuit  designers  often  find  modeling  tools  and  simulation  useful  These  tools  enable  them 
to  test  a  circuit  design  by  simulating  it  rather  than  producing  a  breadboard  version  of  it.  However,  to 
be  useful  these  simulations  must  ha^  e  detailed  models  of  the  components  employed.  Because 
producing  these  models  is  a  time-consuming  task,  they  are  rarely  available  for  the  most  up-to-date 
components.  Simulation  is  not  an  option  for  designs  containing  such  elements.  Furthermore,  the 
designers  themselves  art;  not  sophisticated  enough  in  using  the  tools  to  handle  some  of  the  more 
complex  current  devices,  such  as  microprocessors.  Thus,  even  if  simulation  is  used  to  analyze  detailed 
parts  of  the  circuits  being  designed,  breadboarding  may  still  be  necessary  to  investigate  component 
interactions.  There  are  few  tools  that  support  design  optimization.  Additional  tools  are  needed  that 
address  performance,  cost,  reliability,  producibility,  availability,  etc. 

It  is  unlikely  that  the  entire  design  will  be  at  a  single  level  of  abstraction  at  any  time  except  at  formal 
block  points.  So  to  be  maximally  useful,  an  optimization  tool  must  support  optimization  of  a  design 
represented  at  varying  levels  of  abstraction. 

6.5  HISTORICAL  EMPHASIS  ON  ANALYSIS 

Historically,  emphasis  has  been  on  fixing  a  design  after  an  attempt  has  been  made  at  its 
implementation;  i.e.,  designers  have  historically  used  a  "test,  analyze,  and  fix”  methodology.  The 
emphasis  on  analyzing  for  noncompliance  with  requirements  after  an  initial  attempt  at  the  design 
has  been  made,  is  one  of  the  major  factors  leading  to  the  '.ess-than-optimal  systems  that  have  been 
produced.  In  the  "test,  analyze,  and  fix”  methodology,  effort  goes  into  checking  to  determine  whether 
a  design  has  met  the  requirements  rather  than  designing  it  to  optimally  meet  the  specifications. 

The  basic  process  causes  the  bulk  of  analyses  to  be  performed  after  a  design  has  been  completed.  By 
that  time,  it  is  too  late  to  make  anything  but  patches.  Some  analyses  are  performed  only  to  meet 
requirements,  because  it  is  too  late  for  their  results  to  have  any  effect  on  the  design  In  many  cases, 
as  more  problems  are  found  in  designs,  more  postdesign  analyses  are  added,  rather  than  changing  the 
design  process  to  eliminate  the  problems. 

6.6  DESIGN  DATA  MANAGEMENT 

Present  design  systems  do  not  facilitate  management  of  design  data  There  are  no  adequate  tools 
available  to  manage  the  data  as  the  design  progresses  or  to  ensure  the  validity  of  data  already 
collected  and  being  collected.  Effective  data  management  would  require  a  common  definition  of  the 
characteristics  and  data  elements  of  the  artifact  being  designed. 

The  various  analysis  specialists  all  need  information  from  the  design  engineers  and  other  specialists 
as  the  design  progresses  in  order  to  monitor  design  quality.  Each  specialist  needs  to  know  when  the 
design  has  changed  and  if  the  changes  void  a  previous  analysis. 

The  automated  tools  available  today  do  not  adequately  support  the  concept  of  concurrent  design. 

They  do  not  provide  tools  for  ensuring  adequate  interfacing  between  components  being  designed 
simultaneously  or  checking  to  ensure  that  constraints  affecting  other  processes  are  not  violated. 

Also,  there  are  no  tools  available  that  will  automatically  compare  and  validate  a  design  against  its 
requirements. 

As  the  design  is  decomposed  from  one  hierarchical  level  to  the  next,  requirements  for  each  module  at 
a  level  are  manually  developed  from  the  requirements  of  the  higher  level.  This  process  can  often 
result  incomplete,  vague,  and  inconsistent  requirements. 
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LIST  OF  ACRONYMS 


AC 

alternating  current 

AFB 

Air  Force  base 

AFSC 

Air  Force  Systems  Command 

ALSA 

Automated  Logistics  Support  Analysis 

AMAP 

Automated  Maintainability  Analysis  Program  (SAV) 

AP 

array  processor 

ASD 

Aeronautical  Systems  Division 

ASIC 

application-specific  integrated  circuit 

ATC 

Advanced  Technology  Center 

ATE 

automated  test  equipment 

AWARE 

Avionics  Workstation  Automated  Reliability  Estimator  (S/W) 

BIT 

built-in  test 

BITE 

built-in  test  equipment 

C/O 

checkout 

CAD 

computer-aided  design 

CAE 

computer-aided  engineering 

CARMA 

Computer-Aided  Reliability  Modeling  Analysis  (S/W) 

CD/V 

concept  development  and  validation 

CDR 

critical  design  review 

CDRL 

contract  data  requirements  list 

CE/D 

concept  exploration  and  definition 

CEPFRA 

Computerized  Evaluation  Program  for  Reliability/Availability  (S/W) 

CEQ 

Council  on  Environment  Quality 

CHEAP 

Cost  Effectiveness  Analysis  Program  (S/W) 

Cl 

configuration  item 

CMOS 

complementary  metal  oxide  semiconductor 

D/V 

development  and  validation 

DBMS 

data  base  management  system 

DC 

direct  current 

DFT 

design  for  testability 

DI 

data  item 

DID 

data  item  description 

DIP 

dual  inline  package 

DOD 

Department  of  Defense 

DR&P 

design  rules  and  practices 

DTC 

design  to  cost 

DT&E 

development  test  and  evaluation 

EC  AD 

electronic  computer-aided  design 

ECAE 

electronic  computer  aided  engineering 

ECC 

error  checking  and  correction 

ECL 

emitter-coupled  logic 

EIS 

environmental  impact  statement 

EMI 

electromagnetic  interference 

EMP 

electromagnetic  pulse 

ERL 

engineering  release  unit 

ESCAE 

Electronic  Systems  Computer-Aided  Engineering  (organization) 

ESIL 

ejector/stores  interface  unit 
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LIST  OF  ACRONYMS  (continued) 


FBD 

functional  block  diagram 

FCA 

functional  configuration  audit 

FD 

fault  detection 

FFD 

functional  flow  diagram 

FH 

flight  hour 

FI 

fault  isolation 

FMA 

failure  modes  analysis 

FMEA 

failure  mode  and  effects  analysis 

FMECA 

failure  mode  and  effects  criticality  analysis 

FOT&E 

follow-on  test  and  evaluation 

FRACAS 

Failure  Reporting,  Analysis,  and  Corrective  Action  System 

FRS 

fault  response  sheet 

FSD 

full-scale  development 

FT  A 

fault  tree  analysis 

GIDEP 

Government-Industry  Data  Exchange  Program 

HCI 

human-computer  interface 

HIRD 

hardware  implementation  requirements  document 

HITS 

hierarchical  integrated  test  simulator 

I&C/O 

installation  and  checkout 

I/O 

input/output 

IC 

integrated  circuit 

ICBM 

intercontinental  ballistic  missile 

ICD 

interface  control  document 

IDD 

interface  definition  document 

ILS 

integrated  logistics  support 

IMS 

information  management  system 

IOT&E 

initial  operational  test  and  evaluation 

IR&D 

independent  research  and  development 

LCC 

life  cycle  cost 

LCD 

liquid  crystal  display 

LED 

light-emitting  diode 

LRU 

line-replaceable  unit 

LSA 

logistics  support  analysis 

LSAR 

logistics  support  analysis  record 

MAAA 

maintainability  allocations,  assessments,  and  analysis 

MCSP 

mission  completion  success  probability 

Met 

corrective  maintenance 

Metmax 

maximum  corrective  maintenance 

MDT 

mean  down  time 

MEAP 

Maintainability  Effectiveness  Analysis  Program 

MH 

manhours 

MIL-STD 

military  standard 

MIT 

Massachusetts  Institute  of  Technology 

Mmax 

maximum  maintenance 

MMH 

maximum  maintenance  manhours 

MODAS 

Management  Operational  Data  Access  System 

MR&D 

manufacturing  research  and  development 
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LIST  OF  ACRONYMS  (continued) 


MTBDE 

mean  time  between  downing  events 

MTBF 

mean  time  between  failures 

MTTCF 

mean  time  to  critical  failure 

MTTR 

mean  time  to  repair 

MTTRS 

mean  time  to  restore  sysem 

NASA 

National  Aeronautics  and  Space  Administration 

NC 

numerical  control 

NEPA 

National  Environment  Policy  Act 

Nuc 

nuclear 

PD 

power  dissipation 

PAL 

programmable  array  logic 

PC 

personal  computer 

PC  A 

physical  configuration  audit 

PDP 

program  development  plan 

PDR 

preliminary  design  review 

PgmDR 

program  design  review 

POD 

point  of  departure 

PPL 

preferred  parts  list 

PRICE 

Programmed  Review  of  Information  for  Costing  and  Evaluation 

PRR 

production  readiness  review 

PWB 

printed  wiring  board 

QA 

quality  assurance 

QC 

quality  control 

R&M 

reliability  and  maintainability 

RAAA 

reliability  allocations,  assessments,  and  analysis 

RAM 

reliability,  availability,  and  maintainability 

RAMCAD 

Reliability,  Availability,  and  Maintainability  in  Computer-Aided  Design 

RCA 

Radio  Corporation  of  America 

RDT 

reliability  demonstration  test 

REAP 

Reliability  Effectiveness  Analysis  Program 

RelCalc 

Reliability  Prediction  Program 

RF 

radio  frequency 

RFP 

request  for  proposal 

RM&S 

reliability,  maintainability,  and  supportability 

ROM 

read-only  memory 

SAV 

software 

SCD 

specification  control  drawing 

SDR 

system  design  review 

GIRD 

software  implementation  requirements  document 

SMT 

surface  mount 

SOW 

statement  of  work 

SR 

status  review 

SRAM 

Short-Range  Attack  Missile 

SRR 

system  requirements  review 

SRU 

shop-replaceable  unit 

STE 

special  test  equipment 
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LIST  OF  ACRONYMS  (concluded) 


STROP 

Single-Thread  Reliability  Optimization  Program  (SAV) 

TBD 

to  be  determined 

THERMAL 

Thermal  Effectiveness  Analysis  Program  (S/W) 

TPM 

technical  performance  measurement 

TR 

technical  review 

TRD 

technical  requirements  document 

TTL 

through  transmission  laser 

ULCE 

Unified  Life-Cycle  Engineering 

VLSI 

very-large-scale-scale  integration 

WBS 

work  breakdown  structure 

WCA 

worst  case  analysis 

WIRS 

Wiring  Information  Release  System 
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APPENDIX  A:  DESIGN  PROCESS  TASKS  AND  ANALYSES 


A  1.0  OVERVIEW 

This  appendix  is  a  sampling  of  the  analyses  and  tasks  used  in  the  design  of  electronics.  The  tasks 
listed  are  a  fraction  of  those  needed  to  complete  a  design;  they  deal  mainly  with  the  evolution  of  the 
electronics  portion  of  a  system  from  concept  development  through  detailed  design.  The  tasks  listed  in 
section  A2  0  are  of  a  general  design  nature,  while  those  in  A3.0  deal  primarily  with  electronics 
design 

A  select  subset  of  analyses  versus  their  characteristics  is  shown  in  Table  A-l,  which  lists  the 
important  characteristics  of  each  task. 

Detailed  descriptions  of  the  analyses  and  tasks  follow  Table  A-l.  Each  description  contains  several 
sections  describing  the  important  characteristics  of  the  task  or  analysis,  as  follows: 

•  Description.  Describes  the  task  or  analysis. 

•  Purpose:  Explains  why  and  when  the  analysis  or  task  may  be  used. 

•  Tools.  Lists  any  known,  generally  available,  tools  that  have  been  developed  chiefly  for  the 
purpose  of  performing  or  supporting  the  subject  task  or  analysis.  Only  those  tools  that  perform  or 
support  a  large  percentage  of  the  data  creation  and  management  needs  of  the  subject  task  or 
analysis  are  listed.  Because  they  apply  in  most  situations,  tools  such  as  general  purpose 
database,  documentation,  or  spreadsheet  programs  are  not  listed. 

•  Inputs:  Lists  the  major  data  needed  to  perform  the  analysis  or  task. 

•  Outputs:  Lists  the  major  data  that  the  analysis  or  task  produces. 

•  Where  It  Fits  in  the  Design  Process:  This  section  is  provided  only  where  additional  information, 
beyond  that  provided  in  the  primary  descriptive  sections  above  is  needed  to  determine  the 
phasing  or  prerequisites  of  a  task  or  analysis 

•  Associated  Military  Documents:  Where  applicable,  lists  known  military  handbooks,  standards, 
and  guidelines  that  apply  to  the  analysis  or  task. 

•  Limitations,  Deficiencies,  Problems:  Where  applicable,  lists  any  known  information  in  these 
areas 

Where  there  is  no  information  under  a  particular  heading,  the  heading  is  omitted 
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TABLE  A-1.  Analyses  Matrix 


Analysis 

Purpose 

Design  function 

Tools 

Inputs 

Outputs 

functional 

decomposition 

•  Oecompose 
design  to  lower 
level 

•  Systems  design 

•  RDD  100 

•  Mission 
requirements 

•  System 
requirements 

•  System 
description 

•  Lower  level 
system 
description 
(functional 
flow  and 
functional 
block 
diagrams) 

Functional 
requirements 
and  allocation 

•  identify 
functional  and 
performance 
requirements 
and  allocate  to 
system 
elements 

•  Systems  design 

•  RDD  100 

•  Functional 
flow  diagrams 

•  Functional 
requirements 

•  System 
description 

•  Functional 
block  diagrams 

Life  cycle  cost 
optimization 

1 

1 

1 

j 

I 

•  Optimize 
system  for 
minimum  life 
cycle  costs 

•  Systems  design 

•  CASA 

•  RCA 

PRICE/FAST 

•  System 
description 

•  Cost  data 
(design 

manufacturing 

support) 

•  Cost  summaries 

•  Spares 
requirements 

Fault  detection 
and  fault 
isolation  (FD'Fi) 

•  Determine 
effectiveness 
of  fault 
detection  and 
fault  isolation 
system 

•  Systems  design 

•  Detailed 
design 

•  Reliability  and 
maintainability 

•  Quickfault 

•  Circuit 
description 

•  Test  vectors 
(stimulus) 

•  Fault  list 

•  Failure  rates 

•  Fault 
dictionary 

•  Detection  list 

•  Detection 
stimulus 

False  alarms 

•  Determine 
probability 
that  fault 
detection 
system  will 
report  false 
alarms 

•  Systems  design 

•  Detailed 
design 

•  Reliability  and 
maintainability 

•  logistics 

•  Circuit 
description 

•  FD  -'Fi  data 

•  FMA  data 

•  Fault  monitor 
improvements 

•  False  alarm 
probabilities 

Failure  modes 
analyses  (FMA) 

•  Identify  failure 
modes 

•  Determine  if 

FD-FI  System  is 

adequate 

•  Develop  system 
maintenance 
data 

•  Systems  design 

•  QuickFault 

•  Circuit 
description 

•  Operation 
modes 

•  Failure  modes 

•  Failure  list 

•  Fault  monitor 
improvements 

•  Fault  matrix 

Design 

constraints 

•  Develop  design 
constraints 
applicable  to 
each 

configuration 

item 

•  Systems  design 

•  System 
requirements 

•  System 
description 

•  Design 
constraints  for 
each 

config  jrat.on 
item 
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TABLE  A-1 .  Analyses  Matrix  (Continued) 


Analysis 

Purpose 

Design  Function 

Tools 

Inputs 

Outputs 

Functional 

verification 

•  Verify  that 
design  meets 
functional 
requirements 

•  Systems  design 

•  Detailed 
design 

•  QuickSim 

•  MSPICE 

•SABER 

•  Circuit 
description 

•  Test  stimulus 

•  Expected 
response 

•  Circuit  outputs 

•  Worst  case 
timing 

•  Critical  path 

•  Determine 
timing 
problems  in 
circuit  due  to 
environment 
and  critical 
paths  in  design 

•  Detailed 
design 

•  Circuit 
description 

•  Operational 
modes 

•  Timing 
problems 

•  Critical  paths 

•  Timing 
waveforms 

Worst  case 

•  Evaluate 
minimum  and 
maximum 
voltage  and 
current  levels 

•  Verify  circuit 
performance 
over  range 

•  Detailed 
design 

•  MSPICE 

•  SABER 

•  Circuit 
description 

•  Component 
information 

•  Environment 

•  Circuit 
sensitivity  to 
worst  case 
component 
quality, 
environment, 
power 

•  Evidence  of 
compliance  or 
noncompliance 
with  specs 

•  Circuit  outputs 

loading 

•  Determine 
loading  on 
device  outputs 
to  find 
overloaded 
devices 

•  Oetailed 
design 

•  loading  _ 

Analysis 

•  Circuit 
description 

•  Device 
specifications 

•  Interface 
specifications 

•  Derating  factor 

•  Loading  of 
device  outputs 

•  Outputs 
exceeding 
derated 
loading 
specifications 

Electrical  stress 

•  Fmd  the  powei 
dissipation  of 
electrical 
components  m 
order  to  aid 
reliability 
calculations 

•  Detailed 
design 

•  MSPICE 

•  Circuit 
description 

•  Device 
specifications 

•  Operational 
modes 

•  Power 
dissipation  for 
components 

Testability 

•  Determine  the 
testability  of 
electronic 
circuits  and 
recommend 
improvements 

•  Systems  design 

•  Detailed 

design 

•  Manufacturing 
design 

•  Ti 

•  Circuit 
description 

•  Physical  layout 

•  Operational 
modes 

•  Testability 
rating 

•  Testability 
recommenda 
tions 
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TABLE  A-1 .  Analyses  Matrix  (Continued) 


Analysis 

Purpose 

Design  Function 

Tools 

Inputs 

Outputs 

•  Failure  modes 
effects  analysis 
(FMEA) 

•  Failure  modes 
effects 
criticality 
analysis 
(FMECA) 

•  Determine 
effects  of 
failures  on 
system 

operation  and 
rank  according 
to  severity  and 
probability 

•  Reliability  and 
maintainability 

•  QuickFault 

•  System 
description 

•  8lock  diagrams 

•  Functional 
block  diagrams 

•  Failure  modes 

•  Mission 
functional  and 
operational 
modes 

•  Environmental 
profiles 

•  Mission  times 

•  Reliability 
block  diagrams 

•  Failure  rates 

•  Failure  effects 

•  Failure  seventy 

•  Failure  rates 
and  probability 

•  Operating  time 

•  Failure  effects 

•  Failure 
detection 
method 

•  Compensating 
provisions 

•  Severity 
classification 

•  Item  criticality 

•  Criticality 
matrix 

Preliminary 

layout 

•  Determine  a 
preliminary 
layout  to 
calculate 
reliability, 
testability,  etc 
early  in  design 
to  facilitate 
changes 

•  Oetaiied 
design 

•  Physical  design 

•  Board  Station 

•  Circuit 
description 

•  Package 
specifications 

•  Board 
specifications 

•  Preliminary 
layout 

Thermal  analysis 

•  Determine 
component 
temperatures 
to  calculate 
reliability 

•  Detailed 
design 

•  Physical  design 

•  S»nds 

•  Therm 

•  Circuit 
description 

•  °hys'cal  layout 
and  description 

•  Power 
dissipation 

•  Board  and 
package 
descriptions 

•  Cooling 
descriptions 

•  Temperature 
of  each  device 
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TABLE  A-1.  Analyses  Matrix  (Concluded) 


Analysis 

Purpose 

Design  Function 

Tools 

Inputs 

Outputs 

•  Reliability 

•  Failure  rate 

•  Mean  time 
between 
failures  (MT8F) 

•  Mean  time 
between 

i  downing 
|  events 
;  (MTBDE) 

•  Predict  failure 
rates  of 
components 
and  systems 
and  mean  time 
between 
failures 

•  Reliability  and 
maintainability 

•  AWARE 

•  RelCalc  2, 

SysCalc 

•  RPP 

•  CARMA 

•  CEPFRA 

•  STROP 

•  Circuit 
description 

•  Component 
temperatures 

•  Functional 
description 

•  Redundancy 

•  Component 
failure  rates 

•  System  failure 
rates 

•  Component 
and  system 

MTBF 

•  Component 
and  system 
MTBDE 

Operational 
;  availability 

1 

•  Predict 
operational 
availability  of 
system 

•  Reliability  and 
maintainability 

•  CEPFRA 

•  MIREM 

•  GRAMP 

•  Failure  and/or 
repair  rates 

•  Initial 
reliability 
condition  of 
system 

•  Mission  time 

•  Availability  of 
system 

Mission  success 
probability 

•  Predict 
probability 
that  mission 
can  be 
completed 

•  Reliability  and 
maintainability 

•CARMA 

•  MIREM 

•  GRAMP 

•  FMEA  and 
FMECA  data 

•  Probability  of 
mission  success 

Failure  report 
and  corrective 
action  system 
(FRACAS) 

•  Identify  actions 
to  address 
reliability  and 
maintainability 
problem  area 

•  Reliability  and 
maintainability 

•  System 
description 

•  Field  reliability 
and 

maintainability 

data 

•  Corrective 
actions 
required 

•  Maintainability 
timeline 

•  Mean  time  to 
repair  (MTTR) 

•  Mma* 

•  Predict  repair 
times  and 
determine 
maintenance 
schedules 

•  Reliability  and 
maintainability 

•  AMAP 

•GRAMP 

•  System 
description 

•  FD /  Fi  data 

•  FMA  data 

•  MTBF  and 

MTBDE 

•  Failure  rates 

•  MTTR 

•  Mmax 

•  Maintenance 
schedules 

Fault  tree 
analysis  (FTA) 

•  Safety  analysis 
to  determine 
how  failure 
modes  could 
affect 

property,  life, 
etc 

•  Logistics 

•FTREE 

•  SETS 

•  SEP 

•  Fault  tree  logic 

•  Failure  rates 
and  expose 
times 

•  Fault  tree 
event  failure 
probabilities 

Repair  level 

•  Determine 
Optimum 
location  to 
perform 
repairs  or 
maintenance 

•  Logistics 

•  NRLA 

•  System 
description 

•  FMA  data 

•  Optimal  repair 
time 
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A2.0  SYSTEMS  ENGINEERING 


Systems  engineering  is  a  set  of  techniques  and  procedures  used  to- 

a.  Systematically  develop  and  specify  a  comprehensive,  structured  set  of  functional,  performance, 
design,  and  quality  assurance  requirements  for  the  system  or  project. 

b.  Define  technical,  cost,  and  effectiveness  measures  that  can  be  used  to  manage  the  design, 
development,  construction,  operation,  and  maintenance  of  the  system. 

c.  Optimize  the  system  by  developing  a  configuration  of  subsystems  that  can  cost-effectively  produce 
an  output. 

A2.1  OBJECTIVES  AND  REQUIREMENTS 

The  complete  baseline  mission  and  system  objectives  and  requirements  must  be  clearly,  explicitly, 
and  concisely  documented  before  the  beginning  of  functional  analysis  and  development  of  the  derived 
requirements  and  design  for  each  program,  phase,  project,  or  task. 

A2.I.1  Mission  Objectives  and  Requirements 

The  primary  and  secondary  missions  the  system  is  to  accomplish  must  be  thoroughly  understood  in 
terms  of  need,  user  requirements,  specific  objectives  and  profiles,  operating  environment 
(climatological,  related  systems,  and  threat),  measurement  of  effectiveness,  and  user  operational 
concepts  and  limitations. 
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A2.1.1.1  Needs  Assessment 


Description 

The  user’s  specific  needs  should  be  continually  assessed  by  contractor  study  programs  to  guide 

product  and  technology  development. 

Purpose 

•  To  maintain  the  contractor  in  a  position  to  recognize  and  bid  on  potential  new  business  in  its  area 
of  marketing  interest. 

•  To  assist  in  developing  successful  proposal  strategies  and  presentations. 

•  To  relate  potential  customers'  needs  and/or  functional  deficiencies  to  the  contractor’s  product 
development  potential,  both  immediate  and  long  range. 

•  To  aid  management  in  selecting  and  justifying  new  programs  for  startup. 

Tools 

•  None  commercially  available. 

Inputs 

•  Customer  needs  and  wants. 

Outputs 

•  Assessment,  evaluation,  and  documentation  leading  to  preliminary  design  and  requirements. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  The  needs  assessment  is  done  in  or  prior  to  the  concept  exploration  and 

definition  (CE/D)  phase  and  leads  to  development  of  a  proposal  to  perform 
special  studies  or  to  initiate  the  CE/D  phase  A  needs  assessment  may  also  be 
required  for  definition  and/or  initiation  of  a  major  system  modification 
program.  If  done  prior  to  the  CE/D  phase,  the  needs  assessment  may  be 
updated  at  the  start  of  the  CE/D  phase  and  become  a  reference  for  follow-on 
phases. 

Prerequisites:  Knowledge  of  the  government  system  development  process  and  associated 

sources  of  data  is  required. 
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A2. 1.1.2  Program  Initiation  Documents 
Description 

Authority  to  initiate  a  program  must  be  documented.  For  programs  initiated  by  the  DOD,  the 
acquisition  decision  memorandum  and  related  documents  must  be  obtained.  For  programs  init.ated 
by  Boeing,  authorized  program  scope,  objectives,  and  customer  must  be  explicitly  defined. 

Purpose 

•  To  initiate  study  or  development  activities  on  a  new  program  or  program  phase. 

•  To  authorize  program  o  '  proposal  activities,  including  initial  planning  of  program  development 
activities  by  phases  and  participants. 

Tools 

•  None  commercially  available. 

Inputs 

•  Threat  assessment. 

•  Description  of  current  system  shortfalls. 

•  Alternative  solutions  for  shortfalls,  including  improvement  of  products  in  inventory. 

•  Risk  assessment. 

Outputs 

•  Request  for  equipment  -  to  hardware  or  study. 

•  Statement  of  need  -  to  hardware  or  study. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  The  primary  emphasis  is  on  enabling  a  new  program  to  start  up  However, 
appropriate  authorizing  documents  are  also  required  to  initiate  action  for 
each  program  phase. 

Prerequisites:  For  contractor  initiation  of  new  programs,  the  prerequisite  is  the  completion 

of  needs  assessment  and  product  development  studies.  For  the  contractor  to 
initiate  activity  on  ongoing  programs,  participation  -including  customer 
coordination)  in  and/or  availability  of  results  from  the  mission  and  system 
definition  studies  of  the  preceding  phase  would  be  prerequisites. 


A2. 1.1.3  Mission  Objectives 
Description 

Mission  objectives  must  be  explicitly  documented  in  the  user’s  operational  terms  for  both  primary  and 
secondary  or  tertiary  missions  to  ensure  that  the  contractor  understands  what  the  u=°r  wants  the 
system  to  do.  Th  'y  are  normally  provided  by  the  customer  on  government  programs'  iowever, 
Systems  Engineering  review  and  assessment  are  prerequisites  to  developing  a  contractor  request  for 
proposal  (RFP)  o-  statement  of  work  (SOW)  response.  On  contractor-initiated  program  activities, 
development  of  mission  objectives  by  initiating  the  mission  analysis  of  section  A2.2.2. 1  is  part  of  the 
product  development  initiative  discussed  in  section  A2. 1.2.1. 

Purpose 

•  To  define  in  precise  and  explicit  user  terms  what  the  system  is  to  do 

•  To  serve  as  necessary  inputs  to  the  mission  analysis  in  section  A2  2  2  1  anu  in  general  to  all 
systems  engineering  activities  discussed  in  sections  A2  2,  .2  3.  A?. 4,  and  A2  5 

Tools 

•  None  commercially  available. 

Inputs 

•  Targets,  including  theaters  of  operations  and  mission  definitions,  for  military  systems 

•  Initial  operational  capability  date 

Outputs 

•  ."oecilic  target  descriptions  for  military  weap<  ns 

•  Mission  profiles  for  military  weapons. 

•  Employment  concep  or  military  weapons. 

•  Taiget-  and  munition  matching  data  for  military  weapons. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Understanding  the  mission  objectives  is  essential  to  all  piogram  phases  At 
the  start  of  the  CH/D  phase,  mission  objectives  may  bo  defined  in  the  form  of  a 
technical  requirements  document  (TRD)  During  early  urogram  dev  elopment 
phases,  the  TRD  may  identify  minimum  requirements  uH  objectives  as  well 
as  goals  or  desired  capabilities  By  the  start  of  the  full-scale  development 
(PSD)  phase,  the  mission  objectives  should  be  documented  to  specification 
quality  and  format 

Mission  area  studies  and  needs  assessment  activities  (sec  A2  1  1  hand 
product  development  studies  (sec  A2  12  1)  should  be  performed  as  part  of 
d<  fining  and  refining  a  program's  mission  objectives 
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Prerequisites 


A2. 1.1.4  Operational  Environment  and  Requirements 
Description 

The  total  environment  in  which  the  system  is  to  operate  must  be  defined:  interfacing  systems,  threat 
environments,  limits  on  self-induced  environments,  climatological  environment,  command  structure, 
communications,  operating  personnel  limitations,  and  logistics  constraints.  It  is  normally  provided 
by  the  customer  on  government  programs.  However,  Systems  Engineering  review  and  assessment  are 
prerequisites  to  developing  a  contractor  RFP  or  SOW  response.  On  contractor-initiated  program 
activities,  this  is  part  of  the  product  development  initiative.  However,  in  the  interests  of  total 
program  efficiencies,  some  system-level  trades  may  be  possible  or  desirable  during  early  program 
development  nhases  (e.g.,  deployment  locations  restricted  to  eliminate  undue  cfimatic  extremes,  area 
generation  of  a  mobile  launch  system  used  to  reduce  the  inplace  hardness  required  for  nuclear 
survivability).  However,  these  tradeable  areas  must  be  agreed  to  or  approved  by  the  customer. 

Purpose 

•  To  define  in  precise  and  explicit  terms  the  total  environment  the  system  could  experience. 

•  To  serve  as  necessary  input  to  the  systems  engineering  activities  discussed  in  sections  A2  2,  A2.3, 
A2.4,  and  A2.5:  but  they  may  be  and  should  have  been  developed  using  the  same  interactive, 
iterative  technique 

Tools 

•  None  commercially  available. 

Inputs 

•  Operational  employment  areas  (geographical) 

•  Operating  conditions  (dust,  smoke,  etc.). 

•  Mission  profiles. 

Outputs 

•  Environmental  specification  (for  system  and  segment  specification). 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  The  environmental  specification  is  essential  to  all  program  phases.  At  the 
start  of  the  CE/D  phase,  it  may  he  in  the  form  of  a  technical  requirements 
document  During  early  program  development  phases,  it  may  identify 
minimum  requirements  and  objectives  as  well  as  goals  or  desired  capabilities. 
By  the  start  of  the  ESI)  phase,  it  should  be  of  specification  quality  and  format. 

Prerequisites:  Mission  area  studies  and  needs  assessment  activities  (sec.  A2.1.1.I )  and 

product  development  studies  (sec.  A2  1  2.1)  should  be  performed  as  part  of 
defining  and  refining  a  program's  mission  objectives.  In  addition,  locations  of 
intended  use  need  to  be  defined 
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A2. 1.1.5  Measures  of  Effectiveness 


Description 

System-level  measures  of  effectiveness  must  be  established  and  agreed  upon  with  the  customer  for 
evaluation  of  alternative  concepts  and  designs,  establishment  of  system  success  criteria,  and 
allocation  of  performance  parameter  budgets.  Measures  of  effectiveness  should  be  quantifiable,  but 
many  important  ones  cannot  be  quantified,  so  subjective  ratings  must  be  used  in  those  cases. 

Purpose 

•  To  serve  as  a  common  set  of  standards  and  criteria  for  use  in  selecting  a  preferred  solution  and/or 
verifying  its  suitability.  They  are  prerequisite  to  performing  concept  selection  trade  studies. 

Tools 

•  None  commercially  available 

Inputs 

•  Mission  requirements  for  military  systems. 

•  Targets. 

•  Production  requests  (rate,  quality)  for  civil  systems. 

Outputs 

•  Measures  of  merit  for  managing  system  development. 

•  Technical  (performance  and  design)  measurements. 

•  Cost  (unit  and  life  cycle  cost)  measurements. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Measures  of  effectiveness  are  required  at  a  mission  and/or  system  level  for  the 
CE/D  and  concept  demonstration  and  validation  (CD/V)  phases  They  may  be 
used  at  progressively  lower  levels  to  support  trade  studies  until  completion  of 
technical  design  reviews  (e  g.,  critical  design  reviews). 

Prerequisites:  Mission  objectives,  the  operational  environment  and  requirements,  customer- 

provided  requirements  and  system  constraints  and  nontradeable 
requirements  are  prerequisites. 
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A2. 1. 1 .6  Operational  Concepts 
Description 

The  operational  concepts  and  methods,  interoperability  requirements,  and  high-level  procedures 
must  be  documented  for  each  alternative  concept  evaluated.  The  operational  concept  for  the  system 
concept  selected  should  be  agreed  upon  with  the  using  command.  The  operational  concept  assists 
system  designers  in  identifying  and  allocating  functions,  developing  human-machine  interfaces,  and 
budgeting  performance  allocations.  It  is  normally  provided  by  the  customer  on  government 
programs;  however.  Systems  Engineering  review  and  assessment  are  prerequisites  to  developing  a 
contractor  RFP  or  SOW  response.  On  contractor-initiated  program  activities,  development  of 
operational  concepts  by  initiating  the  mission  analysis  of  section  A2  2.2  1  is  part  of  the  produce 
development  initiative  discussed  in  section  A2. 1 .2  1 

Purpose 

•  To  define  the  user’s  concept  of  operating  the  system  to  achieve  the  mission  objectives  (sec. 

A2  1  1  l!  Operational  concepts  are  necessary  inputs  to  the  mission  analysis  in  section  A2  2  2  1 
and  in  general  to  all  system  engineering  activities  discussed  in  sections  A2.2,  A2.3,  A2.4,  and  A2.5. 

Tools 

•  None  commercially  available 

Inputs 

•  Missions. 

•  Targets. 

•  Threat. 

•  Employment  areas.  •  - 

Outputs 

•  Wartime  operating  concept 

•  Placet  ime  operating  concept 

•  fop-level  maintenance  concept 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Opera!  ional  concepts  are  essential  to  all  program  phases  They  may  be 

preliminary  or  internally  postulated  to  support  the  CE/D  phase  and  even  the 
start  of  the-  CD/V  phase  They  should  be  provided  by  the  customer  (normally 
t  hey  will  be  prepared  by  t  he  user)  and  accepted  or  agreed  to  by  both  the 
custoi'K  r  and  the  user  by  the  start  of  or  early  in  the  FSD  phase. 

Prerequisite:  Mission  an-i  -indies  and  need-,  assessment  activities  (sec  A2.I.1.1)  and 

pi  oiluct  development,  studies  (sec  A2  I  2  1 )  should  be  performed  as  part  of 
delming  and  refining  a  program’s  mission  objectives.  In  addition,  the 
operating  and  support  agencies  or  organizations  should  be  identified. 
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A2.1.2  System  Objectives  and  Requirements 

The  initial  technical  objectives  and  requirements  needed  for  tne  system  to  accomplish  the  defined 
missions  must  be  thoroughly  understood  and  documented  before  the  requirements  analysis  is 
extended  for  each  development  cycle  The  objectives  and  requirements  include  performance, 
availability,  constraints,  maintenance  concepts,  general  verification  concept,  external  interfaces,  and 
the  baseline  concept  or  system  configuration. 

A2.1.2.1  Product  Development  Initiative 

Description 

Contractor- initiated  exploration  of  new  technologies  and  preliminary  design  studies  in  support  of 
contractor  marketing  objectives  should  employ  systems  engineering  methods  and  practices  to  develop 
conceptual  systems  and  technology  development  roadmaps. 

Purpose 

•  To  complement  the  needs  assessment  defined  in  section  A2. 1  1.1. 

•  Specifically,  to  define  how  the  contractor’s  product  development  capabilities  can  be  applied  to 
known  or  perceived  needs  of  a  potential  customer,  or  where  technological  advances  appear  to  have 
potential  for  creating  new  needs  and/or  customers. 

•  To  aid  management  in  prioritizing  and  selecting  areas  of  product  development  and/or  proposal 
activities. 

•  To  define  the  system  concept  and  its  development  approach  for  the  mission  defined  in  section 
A2.1.1.I. 

Tools 

•  None  commercially  available. 

Inputs 

•  An  iterative  process  for  developing  conceptual  solutions  and  establishing  priorities  for  applying 
technological  advances  to  areas  of  known  or  perceived  needs. 

Outputs 

•  System  preliminary  design  definition 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  System  objectives  and  requirements  are  normally  defined  as  a  lead  in  to,  or 

part  of,  the  CE/D  phase  They  may  be  updated  and  refined  as  part  of  the  CD/Y 
phase  and  the  proposal  for  the  FSD  phase.  They  become  reference  material  for 
follow-on  phases 

Prerequisites:  Knowledge  of  contractor  design  and  development  capabilities  and  associated 

technology  development  and  trends  is  a  prerequisite  There  may  also  be  a 
strong  influence  from  the  contractor’s  marketing  strategies,  both  current  and 
long  range. 
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A2. 1.2.2  Customer-Provided  Requirements 
Description 

Customer-provided  system  requirements  must  be  documented,  thoroughly  reviewed,  and  understood 
and  necessary  changes  must  be  negotiated,  before  the  requirements  are  made  a  contractual 
obligation.  Special  attention  must  be  devoted  to  evaluating  the  suitability  and  cost  effectiveness  of 
secondary  and  tertiary  requirements  established  by  reference  in  primary  requirements.  Customer- 
provided  requirements  may  result  in  an  unsolicited  proposal  and/or  coordination  with  the  customer  or 
government  agencies  evaluating  the  need  for  or  seeking  to  establish  a  new  program. 

Not  a  contractor  function. 

Purpose 

•  To  define  the  pe  .  formance  and  characteristics  the  customer  requires  the  system  being  developed  to 
meet  and  demonstrate. 

•  To  vary  specific  activities,  conditions,  or  outputs  of  the  development  process. 

•  To  serve  as  prerequisites  to  initiating  contractor  activities  for  each  phase  and  each  major  systems 
engineering  task  and  specifically  as  inputs  to  functional  analysis. 

Tools 

•  None  commercially  available. 

Inputs 

•  SOW  task  items. 

•  Contract  data  requirements  list  (CDRL  )  items. 

•  TRDs  or  equivalent. 

Outputs 

•  Boeing  requirements  document,  including  derived  requirements. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Customer-provided  requirements  are  applicable  to  all  phases  and  should 

become  progressively  more  detailed  and  definitive  as  the  program  progresses. 
For  the  CE/D  and  CD/V  phases,  requirements  may  be  at  a  high  level,  be 
defined  in  parametric  terms,  and  include  goals  and/or  desires.  As  the  program 
progresses,  requirements  derived  or  made  definite  during  a  phase  may 
become  customer  provided  for  the  next  phase. 
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A2. 1.2.3  System  Constraints  and  Non-tradeabie  Requirements 

Description 

Restraints  and  non-tradeable  requirements  must  be  specifically  identified  prior  to  functional 

analysis,  performance  allocation,  and  verification  of  analysis. 

Purpose 

•  To  define  and  agree  on  conditions  and  boundaries  that  limit  or  constrain  the  operation, 
development,  and  acquisition  of  the  system. 

•  To  similarly  define  and  result  in  agreement  on  system  constraints  that  are  mandatory  or  have 
limits  not  subject  to  tradeoff  considerations. 

•  Mission-  and  system-level  constraints  and  non-tradeable  requirements:  to  guide  and  control  or 
bound  the  entire  system  definition  process. 

•  Detailed  design  constraints:  to  ensure  that  the  design  of  each  element  or  configuration  item  meets 
all  system-level  requirements,  including  those  from  the  specialties  and  disciplines. 

•  To  serve  as  an  integration  tool  for  Systems  Engineering  and  as  a  set  of  design  requirements  for  the 
hardware  and/or  software  designer. 

Tools 

•  None  commercially  available. 

Inputs 

•  Mission  objectives. 

•  Any  design  constraints  and  non-tradeable  requirements  defined  by  the  customer. 

•  System  requirements. 

•  Design  constraints. 

Outputs 

•  Definition  of  constraints  and  non-tradeable  requirements. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  A  definition  of  system  level  constraints  and  requirements  are  critical  for  the 
CE/D  and  CD/V  phases  and  strongly  affect  which  alternative  concepts  are 
developed  and  which  trade  studies  are  performed.  They  should  be  initialized 
and  validated  through  the  CD/V  phase  and  be  inputs  to  the  FSD  phase.  They 
should  be  preliminary  and  incomplete  at  the  start  of  the  FSD  phase,  with 
finalization  as  necessary  to  support  specification  development  and  hardware 
and  software. 

Prerequisites:  Mission  objectives  and  requirements  (sec.  A2. 1 . 1)  should  be  defined  before  the 

highest  or  first  level  of  constraints  and  non-tradeable  requirements  is 
determined  For  more  detailed  design  constraints,  preliminary  functional 
analysis  (sec  A2  2)  and  system  configuration  definition  and  requirements 
allocation  (sec  A2.2  1.3),  should  have  been  accomplished. 


89 


A2.1.2.4  System  External  Interface  Definition 
Description 

Interfaces  external  to  the  system  being  developed  must  be  defined  technically  to  the  degree  ot  detail 
appropriate  for  the  next  level  of  functional  analysis  before  that  level  of  analysis  begins  "External 
interfaces”  include  those  implicit  in  the  operational  environment  (sec.  A2  1.1.4)  and  operational 
concepts  (sec.  A2.1.1.6). 

Purpose 

•  To  define  now  the  system  relates  to  and/or  interacts  with  existing  or  separately  developed  systems, 
installations,  equipment,  or  operations. 

•  Mission  and  system  levels,  to  guide  and  control  or  bound  the  entire  system  definition  process. 

•  To  influence  allocation  of  development  responsibilities  between  contractors. 

•  De  'ign  level:  to  ensure  physical  and  functional  compatibility  with  the  outside  world  when  the 
system  is  deployed  and  operated  in  its  intended  environment. 

Tools 

•  None  commercially  available. 

Inputs 

•  Support  interface  control  activities  and  meetings 

•  Possibly  chair  interface  control  working  group 

•  Identify  externa!  functional  and  physical  interfaces. 

•  Prepare  listing  of  data  required  to  be  exchanged  to  progressively  define  and  control  the  interfaces. 

Outputs 

•  Interface  definition  and  documentation 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  During  early  development  phases  (e  g  ,  CE/D  and  CD/V),  external  interface 
definitions  coordinate  and  guide  the  development  process  and  ensure  that  it 
remains  integrated  within  external  developments.  As  the  design  becomes 
final  (e  g  ,  in  the  FSD  and  production  phases),  the  interfaces  are  defined  and 
controlled  to  ensure  that  the  system  will  fit  and  function  as  intended  in  its 
proper  niche 

Prerequisites:  There  are  none  for  initial  program  startup.  Interface  definition  is  an  integral 

part  of  defining  mission  objectives  and  allocating  them  to  a  system  to  be 
developed  On  major  programs  where  development  is  divided  or  allocated 
among  contractors  with  varying  specialties  (e  g  ,  guidance  and  control 
contractors,  airframe  contractors,  etc.),  the  customer  is  required  to  establish  a 
contract  and  system  acquisition  management  plan.  Detailed  definition  of 
external  interfaces  is  an  integral  part  of  functional  analysis  and  system 
design 
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A2.1.2.5  Phase  Baseline 


Description 

Before  further  analysis  and  design  in  each  iteration  of  a  system’s  design,  the  baseline  or  point  of 

departure  mu=t  be  documented  to  coordinate  engineering  activities,  maintain  configuration 

accounting,  establish  a  basis  for  costing,  assist  in  developing  specifications,  assist  in  identifying 

changes,  and  maintain  control  of  changes  before  implementation. 

Purpose 

•  To  define  and  document  the  system  baseline  at  the  start  and  end  of  each  phase  and  ensure  an 
efficient  transition  between  phases. 

•  To  summarize  and  document  the  current  development  status  of  system  requirements  and  system 
configurations. 

•  To  coordinate  and  track  the  evolution  of  these  requirements  and  configurations,  with  emphasis  on 
the  transition  between  or  across  phases. 

Tools 

•  ECAD/ECAE  schematic  capture  and  documentation  tools. 

Inputs 

•  Mission  objectives,  system  requirements,  and  traceability. 

•  System  specification  and  specification  tree. 

•  System  description 

Outputs 

•  Baseline  documentation 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  A  phase  baseline  is  required  at  the  beginning  and  end  of  each  phase.  It  is  used 
to  define,  in  documented  and  measurable  terms,  the  point  of  departure  for 
phase  start  and  the  result  at  phase  end  The  result  at  the  end  of  a  phase  then 
becomes  the  basis  for  the  point  of  departure  of  the  next  phase. 

Prerequisites:  Identifying  the  phase  baseline  requires  enough  previous  analysis  and  design 

to  establish  a  point  of  departure  for  the  activities  to  be  performed  in  the  next 
phase  or  step  in  the  development  process.  For  the  CE/D  phase,  mission 
objectives  (sec.  A2  1  1  3),  operational  environment  and  requirements  (sec. 

A2  1  1.4),  and  operation  concepts  (sec.  A2.1  1.6)  should  be  established  at  least 
in  preliminary  form.  Also,  at  least  a  preliminary  definition  should  be 
available  for  customer-provided  requirements  (sec.  A 2. 1  2.2),  system 
constraints  and  non-tradeable  requirements  (sec.  A2. 1 .2.3),  and  system 
external  interfaces  (sec.  A2. 1.2.4). 

Limitations,  Deficiencies,  Problems 

•  Existing  tools  do  not  provide  the  needed  data  management  and  documentation  capabilities. 
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A 2.2  FUNCTIONAL  ANALYSIS 


Functional  decomposition  analysis  is  a  method  of  analyzing  performance  requirements  and  dividing 
them  into  discrete  tasks  or  activities.  It  identifies  and  decomposes  the  primary  system  functions  to 
ever  increasing  levels  of  detail,  with  allocation  of  functions  to  system  elements  and  definition  and 
allocation  of  performance  requirements  at  each  analysis  level. 

Functional  decomposition  analysis  is  performed  at  all  levels  of  design.  It  is  used  wherever  the  design 
is  broken  down  to  increasing  levels  of  detail.  Systems  Engineering  uses  it  to  decompose  the  high- 
level  design  concepts  down  to  the  line  replaceable  unit  (LRU)  level  Detailed  Design  uses  it  to 
decompose  the  LRU  down  to  individual  components. 

A2.2.I  Functional  Requirements  Analysis  and  Allocation 

Functional  analysis  is  performed  to  identify  the  characteristic  actions  of  all  the  system  elements 
(hardware,  software,  facilities,  personnel,  procedural  data,  or  combinations  thereof)  and  the 
performance  requirement  for  each  function  to  the  level  of  detail  required  to  initiate  production  design 
and  specify  required  performance  for  each  configuration  item  (Cl)  and  position. 

F unctional  requirements  analysis  and  allocation  is  part  of  functional  analysis  It  consists  of 
functional  flow  analysis,  functional  allocation,  performance  requirements  analysis  and  allocation, 
and  functional  analysis  of  changes. 

Used  by  Systems  Engineering  when  the  design  is  being  decomposed,  this  process  occurs  from  the 
concept  development  phase  through  detailed  design. 


A2.2.1.1  Functional  Flow  Analysis 

Description 

The  functional  analysis  technique  and  format  assist  in  identifying  subfunctions  and  provide  visibility 

of  sequential  and  parallel  relationships  between  functions.  Each  function  has  a  unique  identifier  that 

can  be  used  to  trace  to  both  higher  (parent)  and  lower  (child)  level  functions. 

Purpose 

•  To  identify  system  functions  and  their  sequential  relationships  from  the  top  down  in  a  methodical, 
disciplined  analysis. 

•  To  provide  traceability  from  all  levels  up  to  the  system  and  mission  objectives  and  requirements. 

Tools 

•  Specification  and  requirements  capture  tools:  RDD100  (Ascent  Logic). 

Inputs 

•  System  description. 

Outputs 

•  F unctional  flow  document. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Although  formal  functional  flows  are  not  normally  developed  until  the  CD/V 
phase,  informal  flows  are  used  in  every  phase  and  at  every  level.  Formal 
functional  flows  at  the  system  and  segment  level  should  be  complete  by  the 
end  of  the  CD/V  phase,  and  at  the  prime  or  critical  item  and  operator  level 
early  in  the  FSD  phase.  These  flows  are  established  by  Systems  Engineering 
based  upon  inputs  from  all  design  organizations. 

Prerequisites:  Mission  and  system  objectives,  a  baseline  mission  profile,  and  a  baseline 

operational  concept  should  be  established  and  documented  before  formal 
functional  flow  analysis  starts.  The  functional  flow  is  prerequisite  to 
functional  allocation  and  functional  performance  analysis  and  should  precede 
preparation  of  specifications  at  each  level. 

Limitations,  Deficiencies,  Problems 

•  Available  tools  not  sufficiently  robust  for  large  scale  programs. 

•  Available  tools  have  limited  representation,  analysis,  documentation,  and  data  management 
capabilities. 
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A2.2.1.2  Functional  Allocation 


Description 

Each  function  generated  by  the  functional  flow  analysis  is  allocated  to  hardware  or  software  Cls, 

personnel  and  procedures,  external  systems,  or  logistic  support  subsystems  via  the  system  hierarchy 

(segments,  elements,  subsystems,  etc  ).  An  accounting  of  the  allocation  and  rationale  is  maintained. 

Purpose 

•  To  allocate  required  functions  to  functional  areas,  segments,  subsystems,  hardware  and  software 
configuration  items,  personnel,  procedural  controls,  external  interfaces,  or  the  maintenance  and 
support  logistics  subsystem. 

•  To  maintain  an  accounting  of  the  allocations  made. 

Tools 

•  Specification  and  requirements  capture  tools.  RDD100  (Ascent  Logic). 

Inputs 

•  Functional  flow  data 

•  System  requirements. 

Outputs 

•  Functional  allocations. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Functional  allocations  to  the  Cl  level  are  established  by  Systems  Engineering 
based  on  inputs  provided  by  all  design  organizations.  The  analysis  should  be 
initiated  after,  but  performed  in  conjunction  with,  the  functional  flow  anal  vsis 
at  each  level  in  the  design  (system,  subsystem,  LRU,  etc  ).  A  comprehensive 
analysis  should  precede  specification  preparation.  The  allocations  established 
during  each  design  phase  is  determined  by  the  level  of  design  definition 
required  in  each  phase. 

Prerequisites:  Functions  to  be  allocated  as  well  as  a  preliminary  definition  of  the  system  to 

the  level  to  which  functions  are  to  be  allocated  must  be  defined 

Limitations,  Deficiencies,  Problems 

•  Available  tools  not  sufficiently  robust  for  'urge  scale  programs. 

•  Available  tools  have  limited  representation,  analysis,  documentation,  and  data  management 
capabilities. 
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A2.2.1.3  Performance  Requirements  Analysis  and  Allocation 

Description 

Verifiable  performance,  resource,  and  task  requirements  must  be  determined  and  documented  for 

each  function  identified  by  the  functional  flow  analysis.  They  are  allocated  to  system  hierarchical 

elements  and  configuration  items. 

Purpose 

•  To  analyze,  derive,  quantify,  and  document  the  performance  requirements  for  each  function  and 
task. 

•  To  allocate  these  requirements  to  system  CIs,  facilities,  operating  personnel,  or  support  system 
elements. 

•  To  identify  and  define  tasks  and  required  resources  and  allocate  them  to  the  system  elements. 

Tools 

•  Specification  and  requirements  capture  tools:  RDD100  (Ascent  Logic). 

Inputs 

•  Requirements  for  inspection,  demonstration,  analysis,  or  test 

•  System  requirements. 

•  Success  criteria  for  each  performance  requirement. 

Outputs 

•  Documented  requirement  allocations. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Performance  allocations  to  the  Cl  level  are  established  by  Systems 

Engineering  based  on  inputs  provided  by  all  design  organizations  Draft 
requirements  should  be  prepared  and  during  the  CE/D  phase  and  refined 
during  subsequent  design  phases  A  formal  performance  requirements  and 
allocation  analysis  should  begin  during  the  CD/V  phase  and  must  be 
completed  very  early  in  the  FSD  phase  A  detailed  analysis  may  be  required 
during  the  early  CD/V  phase  to  support  the  design  of  critical  test  or 
demonstration  components  Special  attention  must  be  given  to  scheduling 
requirements  allocation  for  long-lead  items. 

Prerequisites:  The  prerequisites  to  performance  requirements  analysis  and  allocation  are 

functional  flow  analysis  and  functional  allocation.  Several  supporting 
analyses,  including  design  and  trade  studies,  are  also  required  Together  with 
the  requirements  and  constraints  that  are  not  allocated  and  the  non-tradeable 
requirements,  the  allocated  performance  requirements  are  the  basis  for 
preparing  the  specifications  A  partially  completed  performance 
requirements  analysis  is  a  major  input  to  the  design  synthesis  process  Also, 
performance  requirements  analysis  and  allocation  is  a  major  interface  with 
software  and  logistics 

Limitations,  Deficiencies,  Problems 

•  Available  tools  not  sufficiently  robust  for  large  scale  applications. 

•  Available  tools  have  limited  representation,  analysis,  documentation,  and  data  management 
capabilities 
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A2.2.1.4  Functional  Analysis  of  Changes 
Description 

Class  I  and  Class  II  changes  must  be  integrated  into  the  baseline  system  functional  analysis  to  ensure 
identification  of  all  affected  parts  of  the  system,  retain  decision  rationale,  and  maintain  configuration 
accounting. 

Purpose 

•  To  maintain  the  functional  baseline. 

•  To  provide  discipline  on  changes  equal  to  the  initial  design. 

•  To  aid  in  integration  of  changes. 

Tools 

•  None  commercially  available. 

Inputs 

•  Changes  required  to  design. 

•  System  description. 

•  System  requirements 

Outputs 

•  Documentation  of  changes  needed  in  design. 

•  Documentation  of  items  affected  by  changes. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Functional  analysis  of  changes  is  performed  by  th_  group  tha*  currently  has 
control  of  the  design.  Systems  Engineering  performs  this  task  until  the  LRU 
design  phase  and  then  Detailed  Design  takes  over 

Prerequisites:  Prerequisites  are  data  from  the  baseline  functional,  the  functional  allocation, 

and  the  performance  requirements  analysis  and  allocation  analyses. 
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A2.2.2  Supporting  Analyses 


The  functional  analysis  process  includes  many  supporting  analyses.  Several  of  the  most  important 
are  performed  by  the  engineering  specialties,  logistics,  and  the  technical  staff.  The  logistics  support 
analysis  in  particular  must  be  well  integrated  with  the  system  functional  analysis.  Functional 
analysis  methods  are  also  used  in  performing  the  supporting  analyses. 

The  supporting  analyses  include  but  are  not  limited  to  mission  analysis,  timeline  analysis, 
operational  sequence  diagrams,  failure  mode  analysis,  repair-level  analysis,  design  constraints 
analysis,  and  deployment  planning  analysis. 

A2.2.2. 1  Mission  Requirements  Analysis 

Description 

When  mission  objectives  are  lacking  or  incomplete,  the  mission  must  be  analyzed  to  develop  primary 
and  secondary  mission  scenarios  or  profiles  with  supporting  detail  for  each  phase  of  the  mission. 

Purpose 

•  To  develop  a  thorough  understanding  of  the  mission  of  the  system  under  development. 

•  To  break  the  mission  into  its  component  elements. 

•  To  document  the  baseline  primary  and  secondary  missions  of  the  system,  including  the  threats  to 
be  encountered  while  performing  them. 

Tools 

•  None  commercially  available. 

Inputs 

•  Operational  environment  and  requirements. 

•  Mission  requirements. 

•  Operational  concept 

Outputs 

•  Documentation  of  primary  and  secondary  mission  profiles. 

•  Documentation  of  profiles  of  mission  phases. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Mission  analyses  should  be  performed  to  varying  degrees  of  completeness 
until  the  Cl  specifications  are  finalized.  The  baseline  scenarios  should  be 
established  at  the  beginning  of  the  CE/D  phase  as  various  concepts  are 
explored  The  basic  primary  and  secondary  missions  should  be  firm  by  the 
beginning  of  the  CD/V  phase,  as  the  intent  should  be  to  verify  the  validity  of 
chosen  design  concepts. 
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A2.2.2.2  Operating  Concept  Studies 
Description 

Studies  should  develop  an  in-depth  understanding  of  how  the  system  will  be  operated  by  the  user  in 
performing  each  phase  of  a  mission  for  each  operating  mode.  This  understanding  is  input  to  the 
functional  flow  and  requirements  analyses. 

Purpose 

•  To  postulate  alternative  concepts  for  operating  the  system  to  satisfy  the  identified  mission  needs 
and  evaluate  their  effectiveness,  relative  cost,  and  technical  risk. 

•  To  identify  the  primary  and  secondary  operating  modes. 

•  To  develop  an  initial  technical  definition  of  required  external  interfaces. 

Tools 

•  None  commercially  available 

Inputs 

•  Customer  measures  of  effectiveness. 

•  Mission  requirements. 

•  System  concepts 

Outputs 

•  Documented  operating  concepts. 

•  Documented  operating  modes 

•  Documented  external  interfaces 

Where  it  Fits  in  the  Design  Process 

Phase  Application:  Operating  concept  studies  should  be  emphasized  heavily  during  the  CE/D 

phase,  and  baseline  operating  concepts  should  be  established  by  the  beginning 
of  the  CD/V  phase.  The  results  of  the  CD/V  phase  may  drastically  alter  the 
operating  concepts  The  operating  concepts  should  be  fully  established  by  very- 
early  in  the  ESI)  phase. 


98 


A2.2.2.3  Timeline  Analysis 
Description 

Timeline  analyses  or  equivalent  statistical  models  identify  time-critical  functions  and  tasks  and 
allocate  performance  time  requirements  to  subfunctions  and  tasks. 

Purpose 

•  To  determine  whether  time  is  a  critical  factor  for  individual  functions  or  between  functions. 

•  To  identify  the  time-critical  tasks. 

•  To  quantify  action  and  reaction  times  and  operator  workloads. 

Tools 

•  None  commercially  available. 

Inputs 

•  Process  descriptions. 

•  Schedule  requirements. 

Outputs 

•  Time-critical  functions  and  tasks  documented. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  The  level  of  detail  in  the  timeline  analyses  should  progress  through  the 
acquisition  phases  in  parallel  with  mission  analysis,  operational  concept 
studies,  and  functional  identification  and  performance  requirements 
analyses  The  technique  is  used  extensively  during  the  FSD  phase. 
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A2.2.2.4  Operational  Sequence  Diagrams 
Description 

Operational  sequence  diagrams  provide  a  means  of  visualizing  and  analyzing  critical  sequences  of 
events. 

Purpose 

•  To  visualize,  analyze,  and  portray  the  sequence  of  events  and  actions  required  to  perform  critical 
system  operations. 

Tools 

•  None  commercially  available. 

Inputs 

•  Functional  flow  analysis. 

•  Operational  requirements. 

Outputs 

•  Critical  sequences  of  events  documented 
Where  It  Fits  in  the  Design  Process 

Phase  Application:  For  systems  having  sequence-critical  operations,  operational  sequence 

diagrams  are  used  as  an  analysis  tool  during  any  phase.  They  are  also  used  as 
an  input  to  system  operating  procedures  (technical  orders,  software 
development,  operator  position  descriptions,  etc.)  and  should  be  completed  by 
the  beginning  of  system  testing  during  the  CD/V  or  FSD  phases. 
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A2.2.2.5  Failure  Modes  Analysis 
Description 

Failure  modes  analyses  (FMA)  must  be  performed  in  support  of  functional  analysis  and  allocation  to 
determine  the  criticality  of  the  failure  of  each  system  function  or  element,  the  system’s  response  to 
failures,  and  requirements  for  detecting  and  isolating  failures.  Results  of  more  detailed  specialty 
engineering  analysis,  such  as  failure  rates  or  maintenance  and  repair  resource  requirements,  must  be 
integrated  into  performance  requirements  analysis  and  allocation. 

Purpose 

•  To  determine  the  modes  in  which  system  functions  or  elements  can  fail,  the  criticality  of  each 
failure  to  the  mission,  the  means  of  detecting  failures,  and  the  response  to  each  failure. 

•  To  determine  if  the  fault  detection  and  fault  isolation  system  is  adequate. 

•  To  provide  data  to  allow  development  of  system  maintenance  instructions. 

Tools 

•  Fault  tree,  Markov,  and  Monte  Carlo  modeling  tools. 

•  Fault  simulators:  QuickFault,  High  Low  III,  LASAR,  SABER. 

Inputs 

•  System  description  and  block  diagrams. 

•  Operational  modes  and  stimuli. 

•  Failure  rates. 

•  Fault  dictionary. 

Outputs 

•  Documented  recommendations  for  changes  in  the  design  of  fault  containment  regions  and  fault 
monitors 

•  Fault  matrix. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Preliminary,  high-level  failure  mode  analyses  are  started  during  concept 
development  in  the  CE/D  phase.  The  formal  failure  mode  analysis  is 
performed  in  parallel  with  the  functional  analysis,  beginning  in  the  CD/V 
phase  and  finishing  in  the  FSD  phase.  Failure  mode  analyses  must  be 
performed  in  support  of  functional  analysis  and  allocation.  This  analysis  is 
generally  performed  by  a  dedicated  FMA  group 

Limitations,  Deficiencies,  Problems 

•  FMA  is  primarily  a  manual  process  and  very  time  consuming. 

•  A  comprehensive  FMA  requires  detailed  information  (circuit  schematics)  that  is  generally  not 
available  until  late  in  the  design  cycle  As  a  result,  critical  deficiencies  require  costly  redesign 
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A2.2.2.6  Repair-Level  Analysis 
Description 

A  repair-level  analysis  (RLA)  is  used  in  conjunction  with  life  cycle  cost  analysis  to  determine  the 
optimum  location  for  performing  repairs  or  maintenance.  Preliminary  repair  analyses  are  an 
integral  part  of  system  concept  studies  for  systems  posing  questions  about  unusual  repair  locations 
(such  as  space-based  systems).  A  complete  RLA  is  a  part  of  the  logistics  support  analysis. 

Purpose 

•  To  determine  the  optimum  location  for  performing  maintenance  repairs. 

Tools 

•  Network  Repair  Level  Analysis  Model  (AFALC/LSS  Wright-Patterson  AFB). 

Inputs 

•  Failure  rates 

•  Repair  times. 

•  Repair  cost  estimates 

Outputs 

•  Repair  level  recommendations 

•  Detailed  repair  level  costs 

•  Maintenance  requirements. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Initial,  high  level  analyses  are  begun  during  concept  formulation  in  the  CE/D 
phase  Detailed  analyses  for  individual  components  are  completed  by  the  end 
of  the  FSI)  phase  The  complete  RLA  is  a  part  of  the  logistics  support 
analysis 


Limitations,  Deficiencies,  Problems 

•  Available  tools  not  integrated  with  existing  electronic  design  systems. 

•  Available  tools  do  not  effectively  address  all  data  management  and  documentation  needs 
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A2.2.2.7  Design  Constraints  Analysis 
Description 

The  design  constraints  analysis  is  performed  at  the  Cl  level  to  develop,  collect,  and  document 
specification  requirements  that  are  not  strictly  performance  requirements;  these  include  weight, 
envelope,  reliability,  design,  and  construction.  A  design  constraints  scoping  matrix,  plotting 
constraints  against  each  Cl  (including  logistics  support  equipment),  is  prepared 

Purpose 

•  To  develop  and  document  in  specification-type  language  the  design  constraints,  quantified  where 
possible,  applicable  to  each  Cl 

Tools 

•  None  commercially  available 

Inputs 

•  Requirement  allocation  sheets  ( RAS) 

•  Specification  requirements. 

•  Performance  requirements  analysis  and  allocation  data 

Outputs 

•  Design  constraints. 

•  Design  constraints  scoping  matrix 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  The  design  constraints  analysis  is  primarily  applicable  to  the  FSI)  phase 
between  system  design  review  and  the  final  or  system-level  critical  design 
rev  icw.  Preliminary,  high-1*  vel  analysis  should  be  considered  during  the 
later  part  of  the  CF./D  phase  or,  for  prototype  or  test  articles,  during  the  CD/V 
phase 
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A2.2.2.8  Deployment  Planning  Analysis 
Description 

Planning  for  deployment  and  activation  of  a  system  should  use  the  same  methods  and  practices  used 
for  development  of  the  system  to  identify  resource,  technical  data,  and  safety  requirements.  Initial 
operating  capability  may  require  temporary  or  partial  system  configurations. 

Purpose 

•  To  identify  and  allocate  the  functions  and  resources  required  to  deploy  and  activate  the  system. 
Tools 

•  Mission  analysis,  life  cycle  cost,  etc.  programs  such  as  those  listed  in  Table  A-l. 

Inputs 

•  Installation  and  checkout  requirements  analysis. 

•  Operational  requirements. 

•  System  descriptions. 

•  Site  or  environmental  descriptions. 

Outputs 

•  Deployment  plans  and  schedules 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Preliminary  analysis  of  deployment  and  activation  should  begin  during  the 
concept  exploration  phase  for  systems  for  which  these  are  critical  tasks. 
During  the  CD/V  and  FSD  phases,  the  activation  and  deployment  analysis 
should  lag  slightly  behind  the  system  definition.  The  analysis  should  be 
complete  by  very  early  in  the  production  and  deployment  phase  or  by  the  end 
of  the  FSD  phase. 

Limitations,  Deficiencies,  Problems 

•  Available  tools  not  well  integrated 

•  Available  tools  do  not  provide  adequate  data  management  and  documentation  capabilities. 
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A2.3  DESIGN  SYNTHESIS 


At  each  level  of  the  functional  analysis,  designs  that  satisfy  the  functional  and  performance 
requirements  are  synthesized  to  the  level  of  detail  appropriate  for  the  analysis  level.  That  design 
then  guides  the  next  level  of  functional  analysis  and  derivation  of  performance  requirements. 
Verification  requirements  and  facility  requirements  are  also  developed  for  each  level 

The  purpose  of  design  synthesis  is  to  develop  a  system  design  that  accomplishes  the  baseline  mission 
and  system  objectives  and  requirements  and  meets  the  performance  requirements  for  each  allocated 
function.  The  level  of  detail  of  the  postulated  system  will  vary  from  very  broad  conceptual  designs  to 
detailed  assembly  and  production  drawings,  depending  on  the  phase  of  the  project.  Each  aspect  of  the 
design  is  evaluated  as  it  is  proposed  and  may  be  modified  as  a  result  of  the  evaluations,  in  a  repeating 
cycle.  Developing  a  design  solution  for  the  system  is  an  integral  part  of  systems  engineering,  but  the 
design  work  is  usually  performed  in  organizations  that  are  not  called  Systems  Engineering.  A  major 
responsibility  of  the  Systems  Engineering  organization  during  synthesis  is  to  constantly  review  and 
check  to  ensure  that  the  various  parts  of  the  system  are  integrated. 

A2.3.I  Concept  and  Design  Integration 

The  elements  of  postulated  designs  or  concepts  must  be  integrated  into  a  workable  whole  by 
investigation  and  definition  of  interfaces  and  interactions  between  the  elements. 
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A2.3.1.1  State-of-the-Art  Surveys 
Description 

To  increase  competitiveness  and  reduce  technical  risk,  knowledge  of  the  state  of  the  art  of 
technologies  pertinent  to  the  system  under  design  must  be  maintained  by  literature  searches, 
experiments,  and  supplier  surveys. 

Purpose 

•  To  determine  the  state  of  the  art  in  technological  fields  involved  in  a  particular  mission  or  system. 

•  To  provide  input  to  conceptual  design  studies  (sec.  A2.3. 1 .2)  and  system  software  architecture 
studies  (sec.  A2.3.1.3). 

•  To  pro\  ide  information  for  use  throughout  the  design  phase. 

Tools 

•  None  commercially  available. 

Inputs 

•  Review  of  technical  journals  and  papers. 

•  Contacting  and  visiting  suppliers. 

•  Literature  searches. 

Outputs 

•  State  of-the-art  survey  report. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  The  primary  application  is  during  the  CE/D  phase  for  systems  involving  new 
concepts  or  technology  that  is  pushing  the  state  of  the  art.  Product 
improvement  modifications  may  require  initiating  new  surveys  in  specialized 
subject  areas. 

Prerequisites:  The  mission  and  system  objectives  and  requirements  should  be  well 

understood  in  order  to  focus  the  survey  (secs.  A2  1  1 .3,  A2  114,  A2. 1 .2.2,  and 
A2  12  3). 

Limitations,  Deficiencies,  Problems 

•  Manual  and  time  consuming  process.  Survey  results  become  obsolete  quickly. 
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A2.3.1.2  Conceptual  Design  Studies 
Description 

Baseline  and  alternative  system  design  concepts  are  studied  to  visualize  the  resulting  system, 
develop  preliminary  constraints  and  performance  requirements,  provide  information  for  evaluation 
by  trade  studies,  and  identify  areas  of  technical  risk  requiring  further  development. 

Purpose 

•  To  explore,  through  design  studies,  the  concepts  postulated  for  satisfying  mission  and  system 
requirements. 

•  To  begin  to  turn  concepts  into  tangible  designs. 

•  To  feed  the  conceptual  designs  developed  back  to  functional  analysis  (sec.  A2.2)  in  cycles  for 
refinement  and  amplification  of  the  tasks  involved  in  functional  analysis. 

•  To  continually  evaluate  the  conceptual  designs  (sec.  A2.4)  and  serves  as  a  major  input  to 
identification  of  trade  studies  (sec.  A2.4. 1.2). 

Tools 

•  Mission  analysis,  life  cycle  cost,  etc.  programs  such  as  those  listed  in  Table  A  1. 

Inputs 

•  Preliminary  design 

•  State-of-the-art  knowledge 

Outputs 

•  Conceptual  design  studies. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Although  design  studies  of  varying  scope  continue  throughout  the  life  of  a 

program,  conceptual  design  studies  are  performed  predominantly  during  the 
CE/D  phase. 

Prerequisites:  Knowledge  of  the  state  of  the  art  (sec.  A2  3.1.1),  mission  and  system  objectives 

and  requirements  (secs.  A2.1.1  and  A2.1.2),  and  required  high-order  functions 
(sec.  A2  2.1.1)  is  needed. 

Limitations,  Deficiencies,  Problems 

•  Available  tools  not  integrated. 

•  Available  tools  do  not  provide  adequate  data  management  capabilities. 
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A2.3.1.3  System  Software  Architectural  Studies 
Description 

The  system  and  high-level  software  architecture  is  portrayed  on  a  diagram  showing  the  relational 
arrangement  of  the  physical  elements  of  the  system,  software  processing  nodes,  internal  and  external 
communication  links,  communication  switching  nodes,  and  communication  protocols. 

Purpose 

•  To  develop  and  document  the  overall  system  arrangement,  especially  for  communications  and  data 
processing. 

•  To  establish  the  communication  protocols  to  be  used. 

•  To  identify  interfaces  with  other  systems  and/or  command  communications  external  to  the  system 
under  consideration. 

•  To  develop  diagrams  of  system  architecture  for  use  in  internal  communication  of  the  current 
working  baseline  and  inclusion  in  the  system  specification  (sec.  A2.5. 1. 1)  and  technical  review  data 
packages  (sec.  A2.5.2.7). 

•  To  aid  in  identifying  the  subjects  of  trade  studies  (sec.  A2  4.1 .2) 

Tools 

•  Markov  and  Monte  Carlo  modeling  tools. 

Inputs 

•  Preliminary  functional  flow  analysis. 

Outputs 

•  System  software  architectural  studies. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  The  system  architecture  should  be  defined  to  clarify  concepts  -almost  as  a 
means  of  describing  or  defining  each  concept.  Thus,  the  diagrams  are 
prepared  and  repeatedly  refined  during  the  CE/D  phase.  Refinement  should 
continue  through  the  CD/V  phase  and  into  the  FSD  phase,  at  least  until  the 
system  and  segment  specifications  are  authenticated. 

Prerequisites:  The  preliminary  functional  flow  analysis  (sec  A2. 2.1.1)  and  operating  concept 

studies  (sec.  A2.2.2.2)  should  be  available  for  the  definition  of  system 
architecture  to  start.  Conceptual  design  studies  should  progress  in  parallel, 
with  constant  interchange  between  them  and  the  system  architecture  studies 

Limitations,  Deficiencies,  Problems 

•  Available  tools  have  Pmited  representation  and  analysis  capabilities. 

•  Available  tools  do  not  provide  adequate  data  management  capabilities. 
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A2.3.1.4  Models  and  Mockups 
Description 

Physical,  analytical,  and  computer  models  are  used  to  help  visualize  all  or  part  of  the  system  and  to 
analyze  system  response  to  events  and  stimuli. 

Purpose 

•  To  assist  in  visualizing  and  communicating  the  form  of  designs. 

•  For  analytical,  computer,  and  statistical  models,  to  assist  in  visualizing  and  determining  system 
response  to  various  stimuli. 

•  To  be  used  interactively  with  conceptual  design  studies  (sec.  A2.3.1.2)  and  block  diagrams  (sec. 
A2.3.1.5). 

•  To  feed  back  information  to  functional  allocation  (secs.  A2  2. 1.2  and  A2.2.1.3). 

Tools 

•  MCAD  solid  and  wire  frame  modeling  tools. 

•  ECAD/ECAE  schematic  capture  and  documentation  tools. 

Inputs 

•  Design  specifications  and  descriptions. 

Outputs 

•  Model  or  mockup 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Modeling  is  used  during  all  phases,  but  predominantly  during  the  CE/D  and 
CD/V  phases.  Mockups  are  primarily  used  during  the  later  part  of  the  CD/V 
phase  and  the  early  part  of  the  FSD  phase. 

Prerequisites:  Proposed  designs  from  the  design  organization  and  conceptual  design  studies 

(sec  A2  3. 12)  are  needed. 

Limitations,  Deficiencies,  Problems 

•  Available  tools  have  limited  representation  and  analysis  capabilities. 

•  Available  tools  not  well  integrated. 

•  Available  tools  do  not  provide  adequate  data  management  capabilities. 
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A2.3.1.5  Block  Diagrams 

Description 

Schematic  block  diagrams  are  prepared  for  the  system  and  for  major  subsystems  to  portray 

component  functions,  physical  interconnectivity,  and  the  flow  of  information  or  fluids  between 

components.  Schematic  block  diagrams  are  more  detailed  than  system  architecture  diagrams. 

Purpose 

•  To  schematically  portray  the  relationship  and  interconnectivity  between  functions  and/or  physical 
components  of  a  system  or  subsystem. 

•  To  document  the  system  baseline  functional  block  diagrams  (sec.  A2.5.2.2)  and  serve  as  input  to 
the  system  schematics  (sec.  A2.5.2.6). 

•  Frequently,  to  be  included  in  the  technical  review  data  packages  (sec.  A2.5.2.7). 

•  To  define  the  need  for  and  preliminary  input  to  the  interface  control  documents  (sec.  A2.5.2.8). 

•  To  serve  as  input  to  system  models  (sec.  A2.3. 1 .41  and  verification  requirements  (sec.  A2  3.2) 

Tools 

•  ECAF/FCAD  schematic  capture  and  documentation  tools 

Inputs 

•  Functional  flow  analysis 

•  Requirements  allocation  sheets  (RAS) 

Outputs 

•  Schematic  block  diagrams  and  documentation 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Block  diagrams  may  be  used  in  any  phase  and  at  any  level,  but  formal 

documentation  begins  primarily  in  the  CE/D  and  later  phases.  The  diagrams 
should  be  complete  and  under  at  least  internal  configuration  control  by  early 
in  the  FSD  phase.  Similarly,  the  block  diagrams  for  prototype  articles 
constructed  for  evaluation  during  the  CD/V  phase  should  be  placed  under 
configuration  control 

Prerequisites:  System  architecture  diagram  (sec  A2  3.1.3)  and  functional  flow  analysis  (sec 

A2  2  11)  should  be  initiated  at  each  analysis  level  before  the  block  diagrams 
There  is  a  constant  interaction  with  the  functional  flow  analysis  as  each  level 
is  analyzed 

Limitations,  Deficiencies,  Problems 

•  Available  tools  do  not  provide  adequate  data  management  capabilities. 
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Description 

Supplier  surveys  are  conducted  to  determine  the  design  skills  and  products  available  from  industry  to 
support  state-of-the-art  surveys,  conceptual  designs,  design/buy  and  make/buy  decisions,  and  trade 
studies. 

Purpose 

•  To  determine  the  design  skills  and  products  available  from  industry  to  support  the  concepts  and 
system  designs  under  consideration. 

•  During  the  PSD  and  production  and  deployment  phases,  to  determine  the  quality  and  production 
capacity  (producibility)  of  selected  suppliers. 

•  To  support  trade  studies  (sec.  A2.4. 1.2),  functional  analysis  (sec.  A2.2),  design  studies  (sec. 

A2.3  1  2),  architectural  studies  (sec.  A2.3.1.3),  block  diagrams  (sec.  A2.3.1.5),  and  producibility 
evaluations  (sec.  A2.4. 1.  3). 

Tools 

•  None  commercially  available. 

Inputs 

•  Same  as  state  of  (he  art  surveys. 

Outputs 

•  Supplier  survey  results  and  reports. 

Where  It  Pits  in  the  Design  Process 

Phase  Application:  Supplier  surveys  may  be  part  of  state-of-the  art  surveys  during  the  CE/D 
phase.  They  are  used  separately  to  support  functional  analysis,  design 
studies,  and  architectural  studies  during  the  CE/D,  CD/V,  and  FSD  phases. 
They  support  block  diagrams  and  producibility  evaluations  during  the  early 
FSD  phase  and  trade  studies  during  all  phases. 

Prerequisites:  Mission  and  system  objectives  and  requirements  (sec.  A 2  1 ) ,  initial  functional 

How  analysis  (sec.  A2  2. 11),  and  initial  state-of-the-art  surveys  (sec. 

A2.3  1.1)  must  be  started. 

Limitations,  Deficiencies,  Problems 

•  Manual  and  time  consuming  process  Survey  results  become  obsolete  quickly. 
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A2.3.1.7  Specification  Tree 

Description 

The  specification  tree  portrays  the  hierarchical  relationship  for  all  the  specifications  applicable  to  a 

system.  Specifications  must  represent  each  deliverable  item  or  increment  of  the  system,  and  the  tree 

must  parallel  the  work  breakdown  structure  (WBS).  The  tree  will  determine  the  list  of  CIs. 

Purpose 

•  To  identify  and  document  the  hierarchical  relationship  of  all  specifications  for  a  system  down  to  the 
lowest  Cl  level. 

•  To  provide  administrative  control  of  preparation  of  the  specification  baseline  (sec.  A2.5. 1)  and 
information  in  the  technical  review  data  packages  (sec.  A2.5.2.7). 

•  To  identify  interfaces  between  suppliers’  products  that  require  interface  control  documents  (sec. 
A2.5.2.8). 

Tools 

•  Specification  and  requirements  capture  tools:  RDD100  (Ascent  Logic). 

Inputs 

•  Work  breakdown  structure 

Outputs 

•  Specification  tree. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Draft  trees  should  be  prepared  during  the  CK/D  and  early  CD/V  phases  for 

feasible  system  concepts.  Late  in  the  CK/D  phase,  a  tree  should  be  prepared  as 
part  of  the  proposal  for  the  CD/V  phase  Similarly,  a  tree  should  be  prepared 
late  in  the  CD/V  phase  as  part  of  the  proposal  for  the  FSD  phase.  The  tree 
should  be  complete,  agreed  to  with  the  customer,  and  under  internal 
configuration  control  early  in  the  FSD  phase,  prior  to  authentication  of  the 
FSD  system  specification  engineering  change  proposals  throughout  the  life 
of  the  system  may  cause  changes  to  the  tree. 

Prerequisites:  Functional  allocation  (sec.  A2. 2. 1 .2),  system  architecture  (sec  A2.3  1  3),  and 

block  diagrams  (sec  A2.3. 1 .5)  are  required 

Limitations,  Deficiencies,  Problems 

•  Available  tools  not  sufficiently  robust  for  large  scale  applications 

•  Available  tools  have  limited  representation,  analysis,  documentation,  and  data  management 
capabilities 
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A2.3.2  Verification  Requirements 


Requirements  are  developed  for  verifying  that  each  performance  and  design  requirement  has  been 
satisfied.  The  statement  of  verification  requirements  must  include  the  criteria  by  which  completion 
will  be  judged  successful.  Traceability  must  be  maintained  between  the  requirement  being  verified, 
the  verification  requirement,  and  the  evidence  of  compliance.  Verification  of  individual  requirements 
is  completed  at  the  lowest  level  possible  in  the  system. 

Development  of  formal  verification  requirements  during  the  synthesis  of  a  concept  or  system  design  is 
an  integral  part  of  the  synthesis  process.  By  developing  the  test  concepts  and  methods  at  the  same 
time  as  the  design,  designs  and  requirements  that  are  not  testable  or  require  disproportionate 
resources  to  test  can  be  modified  or  rejected.  Similarly,  requirements  for  built-in  test  or  features  tha' 
aid  testing  can  be  determined  early,  which  will  not  only  help  the  verification  program  but  also 
improve  maintainability. 

The  formal  verification  process  is  generally  called  the  "test  program,’’  but  demonstrations,  analyses, 
and  special  engineering  inspections  are  also  used  to  verify  compliance  with  the  specification 
requirements  The  formal  verification  program  does  not  include  engineering  experimental  and 
developmental  testing. 

In  most  cases,  several  copies  of  each  Cl  are  produced  to  the  same  design.  In  those  cases,  the  design  is 
qualified  during  the  verification  program,  and  quality  assurance  in  production  verifies  that  each  cop 
is  the  same  as  the  qualified  design  At  the  segment  and  system  level,  however,  it  is  common  to 
produce  only  one  item,  or  very  few  items,  so  it  is  not  cost  effective  to  qualify  the  design  in  the  same 
way  as  for  a  production  run  In  these  cases,  as  much  verification  as  possible  is  performed  at  lower 
levels,  but  final  verification  is  usually  performed  on  the  whole  system  to  be  delivered,  or  even  at 
delivery,  to  verify  that  the  system  as  a  whole  complies  with  the  requirements  of  the  specification. 
Traceability  must  be  maintained  from  the  requirements  to  the  reports  and  analyses  that  verify 
compliance  so  that  complete  compliance  with  the  specification  is  documented  for  contract  closeout. 
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A2.3.2. 1  Test  Concepts 
Description 

The  overall  plan  and  concept  for  the  test  program  must  be  documented,  usually  in  the  system  test 
plan.  The  test  concept  must  be  consistent  with  the  test  and  evaluation  management  plan  (TEMP)  if 
one  is  furnished  by  the  customer.  A  building-block  concept,  proceeding  from  the  lowest  level 
components  up  to  the  system  level,  is  considered  standard. 

Purpose 

•  To  provide  an  overall  concept  for  structuring  the  verification  program  that  establishes  and 
confirms  the  performance  of  the  system  and  provide  a  basis  for  acceptance  of  production  articles 
and  the  assembled  system 

•  To  be  used  in  preparation  of  the  system  specification  (sec.  A2.5. 1.1),  source  control  documents 
(SCD)  (sec.  A2.5. 1.4),  and  development  test  plans  (sec.  A2.4.2). 

Tools 

•  None  commercially  available. 

Inputs 

•  Test  instruction  sheets  (TIS). 

•  Test  requirements. 

Outputs 

•  System  test  plan. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Preliminary  development  of  the  test  concept  occurs  during  the  CE/D  phase. 

The  concept  is  refined  and  upgraded  during  the  CD/V  phase.  It  must  be  firm 
by  the  beginning  of  the  FSD  phase. 

Prerequisites:  The  system  architecture  and  general  composition  (sec.  A2.3.1)  must  be 

known.  The  organization  and  the  WBS  must  have  been  selected.  At  least 
preliminary  performance  requirements  (sec.  A2.2.1.3)  must  be  established 

Associated  Military  Documents 

•  DODD  5000.3,  Test  and  Evaluation. 


114 


A2.3.2.2  System  Verification  Requirements 
Description 

A  verification  requirement  is  documented  for  each  performance  and  design  requirement  of  each 
specification.  It  contains  the  criteria  for  successful  verification.  A  single  test,  demonstration, 
inspection,  or  analysis  frequently  verifies  several  individual  requirements.  Verification 
requirements  should  be  stated  so  they  can  be  completed  at  the  lowest  possible  level  of  system 
component  or  subassembly.  Traceability  between  performance  and  verification  requirements  must 
be  maintained. 

Purpose 

•  To  establish  specific  requirements  for  verifying  the  design  and  performance  requirements  of  the 
system,  segment,  and  configuration  item  specifications. 

•  To  be  used  in  completion  of  the  specifications  (sec.  A2.5.1). 

•  To  initiate  planning  for  formal  verification  testing  (secs.  A2.4  2.3  and  A2  4.2.4). 

Tools 

•  None  commercially  available. 

Inputs 

•  Success  criteria  for  verification  requirement. 

Outputs 

•  Verification  cross-reference  matrix 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Verification  requirements  should  be  considered  during  the  CK/I)  phase  but 

are  not  formally  documented  until  the  specifications  are  written  Verification 
requirements  for  demonstration  articles  will  be  required  in  the  CI)/V  phase 
and  must  be  completed  for  the  operational  system  before  the  test  program  of 
the  FSD  phase  begins. 

Prerequisites:  The  test  concept  (sec.  A2. 3. 2. 1)  must  be  developed,  as  must  the  specification 

design  and  performance  requirements  (sec.  A2.2  1.3). 

Associated  Military  Documents 

•  MIL-STD-490A  (Hardware) 

•  M1L-STD-483A  (Software). 
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A2.3.2.3  Checkout  Requirements 


Description 

Requirements  for  Quality  Assurance  verification  that  system  increments,  installations,  and 
subassemblies  are  operating  correctly  (checkout)  before  system  development  continues  must  be 
documented.  Increments  to  be  checked  out  are  chosen  to  aid  fault  isolation  and  to  ensure  that  the 
next  assembly  or  installation  operation  can  be  performed  without  damage  to  property  or  injury  to 
personnel 

Purpose 

•  To  verify  that  installations  are  correct  and  that  the  installed  elements  of  the  system  are  operating 
correctly. 

•  To  identify  any  special  equipment,  software,  and  procedures  necessary  to  install,  assemble,  or 
connect  and  check  out  the  system  to  verify  that  it  is  ready  for  operation. 

•  Potentially,  to  impact  or  influence  the  design  of  system  elements  (sec.  A2.4.2.5). 

Tools 

•  None  commercially  available. 

Inputs 

•  Preliminary  or  final  technical  orders  (TO),  if  possible. 

Outputs 

•  Checkout  requirements  document 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Checkout  concepts  and  planning  should  be  considered  during  all  phases  as  the 
design  progresses  Specific  checkout  requirements  are  needed  for  each  phase 
during  which  deliveries  are  to  be  made;  for  example,  test  articles  during  the 
C!)/V  phase.  Checkout  requirements  may  be  prepared  late  in  the  FSD  phase 
or  early  in  t  he  production  phase;  they  must  be  complete  prior  to  production. 

Prerequisites:  Inputs  from  concept  design  studies  (sec.  A2.3. 1.2),  deployment  and  activation 

functional  analysis  (sec  A2.2  2  8),  and  hardware  and  software  design  during 
PSD  are  necessary 
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A2.3.2.4  Acceptance  Test  Requirements 
Description 

Requirements  for  inspection,  demonstration,  and  testing  to  verify  that  production  CIs  and  system 
delivery  increments  are  acceptable  for  delivery  must  be  documented.  Requirements  may  be  for 
acceptance  by  Boeing  for  future  delivery,  for  acceptance  by  Boeing’s  customer,  or  both. 

Purpose 

•  To  define  the  inspections,  demonstrations,  and  tests  required  for  acceptance  of  each  delivery  Cl  and 
system  increment  by  Boeing  from  suppliers  or  by  the  customer  from  Boeing;  i.e.,  to  establish  the 
criteria  for  successful  delivery. 

•  To  provide  the  technical  basis  for  contractual  acceptance  of  each  delivered  article,  system 
increment,  and  system. 

•  To  provide  a  significant  part  of  the  product  baseline  (sec.  A2.5  1). 

Tools 

•  N'one  commercially  available. 

Inputs 

•  Test  verification  requirements 

•  Completion  or  design  and  performance  requirements. 

Outputs 

•  Acceptance  test  procedures. 

•  Acceptance  test  requirements. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  All  phases  after  the  CK/I)  phase  that  require  delivery  of  articles,  increments, 
or  the  entire  system. 

Prerequisites:  Prerequisites  are  completion  of  the  design  and  performance  requirements 

portion  of  the  specifications  (sec.  A2.5  1 ),  the  test  concept  (sec.  A2.3  2  1 1,  and 
the  verification  requirements  (secs.  A2.3.2.2  and  A2  3  2  3). 
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A2.3.3  Facility  Requirements 

Requirements  must  be  developed  and  documented  for  facilities  that  are  an  integral  part  of  the  system 
or  that  house  and  support  the  prime  mission  equipment  (PME),  the  interfaces  between  the  PME  and 
facilities,  the  design  and  construction  of  the  facilities,  and  acceptance  of  facilities. 

This  general  category  of  tasks  develops  the  requirements  for  facility  resources  to  house  and  support 
the  system  under  development  and  defines  the  interfaces  between  the  facilities  and  the  prime  mission 
equipment.  In  some  cases,  the  facilities  are  an  integral  part  of  the  system  being  developed,  but  in 
others,  the  facilities  simply  house  and  support  the  prime  mission  system  and  its  supporting  elements. 
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A2.3.3.1  Facility  Identification 

Description 

Facilities  required  as  part  of  the  system,  to  house  the  system  elements,  or  to  support  operat  ion  and 

maintenance  of  the  system  must  be  identified  and  documented. 

Purpose 

•  To  identify  and  define  the  facility  resources  required  to  house  and  support  the  prime  mission 
system. 

•  To  develop  the  more  detailed  requirements  in  the  next  iteration  of  the  functional  performance 
analysis  (sec.  A2.2  1.3),  interfaces  (sec.  A2.3.3.2),  criteria  (sec.  A2.3.3.3),  and  acceptance 
requirements  (sec.  A2.3.3.4). 

•  To  be  used  in  communication  with  outside  agencies  and  contractors. 

Tools 

•  None  commercially  available. 

Inputs 

•  Requirement  allocation  sheets  (RAS) 

•  Definition  of  facility  resources 

Outputs 

•  Documented  facility  identification  criteria  and  requirements. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  For  systems  that  include  the  facilities  as  an  integral  part  of  the  concept,  such 
as  silo-based  ballistic  missiles,  high  level  facilities  requirements  are 
generated,  traded,  and  evol  v-ed  very  early  during  the  CE/D  phase.  All 
specially  constructed  facilities  are  long  lead,  so  the  requirements  should  be 
identified  as  early  as  possible  in  the  development  phases;  frequently,  they 
must  be  identified  and  defined  in  increments  to  allow  design  and  construction 
to  proceed  on  schedule.  Thus,  the  major  parameters  of  facilities  may  have  to 
be  identified  and  put  under  configuration  control  during  the  CD/V  phase, 
prior  to  starting  the  FSD  phase.  During  FSD,  the  facilities  requirements 
should  be  established  very  early.  Separating  the  more  detailed  requirements 
into  separate  documentation  (secs.  A2.3.3.2  and  A2.3.3.3)  helps  the 
scheduling  problem. 

Prerequisites:  Prerequisites  are  functional  analysis  (sec.  A2.2),  system  architecture  (sec. 

A2  3. 1  3),  operational  environment  and  requirements  (sec.  A2.1.1.4), 
operational  concepts  (sec.  A2  1.1.6)  and  system  objectives  and  requirements 
(sec  A2  1.2). 
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A2.3.3.2  PME/Facility  Interface  Requirements 

Description 

Requirements  for  interfaces  between  prime  mission  equipment  and  the  facility  it  is  used  in  must  be 

documented.  Transient  or  temporary  and  physical  interface  requirements  should  be  included,  as  well 

as  permanent  mechanical  and  electrical  connection  interface  requirements. 

Purpose 

•  To  identify  and  define  requirements  for  physical  interfaces  between  the  prime  mission  equipment 
installed  or  used  in  a  facility  and  the  facility. 

•  To  be  input  to  facility  acceptance  (sec.  A2.3.3.4),  facility  criteria  (sec.  A2.3.3.3),  and  interface 
baseline  control  (sec.  A2.5.2.8). 

•  To  be  used  in  communication  with  agencies  and  contractors  designing  the  facilities. 

Tools 

•  None  commercially  available. 

Inputs 

•  Preliminary  designs  of  items  to  be  'uncalled. 

•  Block  diagrams. 

•  Facility  identification. 

Outputs 

•  Facility  interface  requirements  document. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Specific  information  about  facility  interfaces  is  not  normally  developed  until 
the  PME  is  fairly  well  defined.  For  prime  or  critical  Cls,  evaluation  of  facility 
interfaces  may  be  required  during  the  CE/D  phase  as  an  input  to  trade 
studies.  For  test  or  demonstration  installations,  complete  definition  may  be 
required  during  the  CD/V  phase;  however,  detailed  interface  requirements 
are  not  usually  developed  until  the  FSD  phase.  Schedule  demands  for  long- 
lead  facilities  may  require  early  partial  definition  of  interfaces,  with 
incremental  releases  until  they  are  complete.  If  the  customer  considers 
construction  of  facilities  to  be  part  of  the  production  phase,  the  start  of  the 
production  phase  will  overlap  the  FSD  phase,  so  the  demand  timing  of  facility 
interface  definition  will  change  little. 

Prerequisites:  Prerequisites  are  block  diagrams  (sec.  A2.3.I  .5),  facility  identification  (sec. 

A2  3  3.1),  and  layouts  or  preliminary  designs  of  the  items  to  be  installed  in 
the  facility. 
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A2.3.3.3  Facility  Criteria 
Description 

Documentation  of  facility  criteria  must  include,  directly  or  by  reference,  all  requirements  imposed  by 
the  system  on  facilities  for  the  system.  Requirements  are  written  in  specification-like  language.  The 
agency  procuring  the  facilities  normally  prepares  the  specifications  incorporating  the  facilities 
criteria. 

Purpose 

•  To  provide  formal  documentation  of  the  specification-type  requirements  imposed  by  the  mission 
system  on  facilities. 

•  To  serve  as  input  for  facility  acceptance  documentation  (sec.  A2.3.3.4),  baseline  documentation 
(sec.  A2.5.2. 10),  and  communication  with  external  facilities  agencies  and  contractors. 

Tools 

•  None  commercially  available. 

Inputs 

•  Engineering  requirements. 

•  Manufacturing  requirements. 

Outputs 

•  Facilities  requirements  documents. 

•  Facilities  criteria  document. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  For  test  prototypes,  the  criteria  for  those  facilities  needed  to  complete  the 

demonstration  and  tests  are  documented  during  the  CD/V  phase.  Similarly, 
criteria  for  long-lead  facilities  needed  during  the  FSD  phase  may  have  to  be 
prepared  during  the  CD/V  phase.  Normally  the  facilities  criteria  are  prepared 
during  the  design  portion  of  the  FSD  phase. 

Prerequisites:  Prerequisites  are  requirements  analysis  and  allocation  (sec.  A2.2.1),  system 

architecture  (sec.  A2.3.1.3),  facility  identification  (sec.  A2.3.3.1),  and 
PME/facility  interface  requirements  (sec.  A2.3.3.2). 

Associated  Military  Documents 

•  MIL-STD-490A,  Specification  Practices. 
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A2.3.3.4  Facility  Acceptance 

Description 

The  technical  inspections,  tests,  demonstrations,  and  analyses  performed  or  audited  prior  to 

acceptance  of  facilities  must  be  documented;  routine  quality  assurance  inspections  may  be  omitted. 

Acceptance  requirements  must  not  impose  requirements  not  included  in  the  facilities  criteria  to 

which  the  facility  was  constructed. 

Purpose 

•  To  plan  and  document  the  engineering  requirements  for  inspection  and  test  of  facilities  prior  to 
acceptance  or  turnover  for  installation  of  mission  equipment. 

•  To  transmit  engineering  requirements  to  Operations. 

Tools 

•  None  commercially  available. 

Inputs 

•  Facility  criteria 

•  Engineering  requirements  for  acceptance  and  test. 

Outputs 

•  Facility  acceptance  requirements  document. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Some  facilities  requiring  acceptance  may  be  needed  during  the  CD/V  phase 
for  demonstration  of  prototypes,  but  normally  all  system  facilities  are 
accepted  beginning  early  in  the  production  and  deployment  phase.  The 
acceptance  requirements  should  be  prepared  late  in  the  FSD  phase  or  during 
the  P/D  phase  before  particular  facilities  need  to  be  accepted;  eg, 
incrementally. 

Prerequisites:  Facility  criteria  (sec.  A2  3.3.3)  and  facility  criteria  baseline  control  (sec. 

A2.5.2  10)  are  needed. 
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A2.4  EVALUATION  AND  DECISION 


As  each  design  solution  is  synthesized  and  postulated,  it  must  be  evaluated  against  the  functional 
and  performance  requirements  of  the  system,  and  a  decision  must  be  made  about  whether  to  move  the 
working  baseline  to  include  it.  Frequently,  the  results  of  the  evaluation  process  feed  back  to  modify 
functional  analysis  and  generation  of  requirements  or  even  the  system  objectives.  Trade  studies, 
analyses  by  specialty  engineering  disciplines,  testing,  and  program  reviews  are  the  major  means  of 
evaluation. 

A2.4.1  Study  and  Analysis 

Studies  and  technical  analyses  supported  by  engineering  tests  are  the  primary  tools  used  to  evaluate 
designs  until  prototype  equipment  becomes  available.  Trade  studies,  sensitivity  analyses,  and 
evaluation  analyses  by  specialty  engineering  disciplines  are  the  major  means  of  evaluating  designs. 
Technical  performance  parameters  are  established  to  track  progress  toward  performance  objectives. 
Support  system  analyses  evaluate  the  supportability  of  proposed  designs. 


123 


A2.4.1.1  Technical  Performance  Measurement 


Description 

Requirements  for  key  and  critical  performance  parameters  are  established  as  technical  performance 
measurements  (TPM).  As  design  progresses  and  analysis  and  test  data  become  available,  progress 
toward  achieving  each  requirement  is  tracked  and  presented  graphically.  TPMs  are  used  as  a 
measure  of  technical  program  development  status  by  management  and  the  customer.  Parameters 
that  are  go/no-go  or  that  can  be  met  without  development  are  poor  choices  for  TPMs. 

Purpose 

•  To  periodically  forecast  the  values  of  selected  performance  measures  to  give  management  early 
visibility  of  problems  and  support  assessment  of  proposed  program  changes. 

•  To  evaluate  the  technical  status  of  the  program  and  take  timely  action  if  it  appears  that  the 
program  will  not  meet  its  technical  goals. 

Tools 

•  None  commercially  available. 

Inputs 

•  Analyses,  including  results  of  trade  and  sensitivity  studies,  to  identify  key  performance  areas  to  be 
tracked  (10  to  12different  parameters). 

Outputs 

•  TPM  report,  updated  periodically 
Where  It  Fits  in  the  Design  Process 

Phase  Application:  TPMs  are  normally  used  late  in  the  CD/V  phase,  then  in  the  FSD  and 
production  phases 

Prerequisites:  Major  prerequisites  or  inputs  to  this  task  are  measures  of  effectiveness, 

outputs  of  trade  and  sensitivity  studies;  specialty  engineering  analysis;  and 
concept,  design,  and  operational  assessment  and  test. 

Associated  Military  Documents 

•  MIL-STD-499A,  Engineering  Management. 

•  "Systems  Engineering  Management  Guide,”  Ft.  Belvoir,  VA.,  Defense  Systems  Management 
College,  Chapter  14,  p  14-1. 
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A2.4. 1.2  Trade  Studies  and  Sensitivity  Analyses 


Description 

Trade  studies  are  the  decision-making  tool  used  to  evaluate  and  resolve  choices  between  postulated 
solutions  at  branches  (decision  points)  in  the  functional  analysis  and  design  synthesis  processes. 

They  trade  interdependent  program  or  design  parameters  to  determine  the  best  balance  between  or 
among  the  parameters.  Sensitivity  studies  determine  the  sensitivity  of  selected  parameters  to 
changes  in  other  parameters.  Documentation  of  trades  and  sensitivity  analyses  records  the  rationale 
for  program  decisions  and  provides  a  baseline  for  evaluating  future  changes. 

Purpose 

•  To  determine  the  best  setting  for  all  system  parameters  that  can  be  controlled  by  engineering.  This 
includes  ensuring  that  not-to-be-exceeded  parameters  such  as  cost  are  met  and  that  the  selected 
parameters  result  in  a  system  in  which  capability  is  not  sensitive  to  reasonable  changes  in  any  of 
the  parameters. 

•  To  make  program  decisions. 

•  To  serve  as  inputs  in  generating  the  next  level  of  functions  and  performance  requirements  in  the 
functional  analysis  (sec.  A2.2.1),  making  decisions  on  designs  (sec.  A2.3.1),  and  determining 
intermediate  system  baselines  (sec.  A2.5.2). 

Tools 

•  Mathematical  models. 

•  Mission  analysis,  life  cycle  cost,  etc.  programs  such  as  those  listed  in  Table  A-l. 

Inputs 

•  Figures  of  merit  and  measures  of  effectiveness. 

•  Alternative  systems. 

•  Functional  analyses. 

Outputs 

•  Trade  study  results. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Trade  studies  are  made  in  all  phases  of  the  development  cycle.  Mission-  and 
concept-level  trades  are  made  during  the  early  phases,  and  detailed  trades 
concerning  unexpected  changes  are  made  during  the  late  phases. 

Prerequisites:  Inputs  to  trade  studies  are  functional  analysis  (sec.  A2.2);  concept  and  design 

integration  (sec.  A2.3.1);  measures  of  effectiveness  (sec.  A2. 1.1. 5);  analytical 
models  and  simulations  (sec.  A2.3.1.4);  results  of  specialty  analyses  such  as 
reliability,  safety,  and  human  factors  (sec.  A2.4. 1 .3);  concept,  design,  and 
operations  assessment  studies  (sec.  A2.4. 1.4);  and  tests  (sec.  A2.4.2). 

Limitations,  Deficiencies,  Problems 

•  Available  tools  not  well  integrated. 

•  Available  tools  do  not  provide  adequate  data  management  capabilities. 
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A2.4.1.3  Specialty  Engineering  Analyses  and  Evaluations 
Description 

The  major  specialty  engineering  disciplines  are  reliability,  maintainability,  safety,  human  factors, 
electromagnetic  compatibility,  corrosion  control,  survivability  and  vulnerability,  producibility,  and 
security  engineering.  The  requirements  of  these  disciplines  are  included  in  the  performance 
requirements  of  the  functional  analysis  and  subsequently  in  the  specifications.  Postulated  design 
solutions  must  be  evaluated  by  these  disciplines  for  compliance  with  requirements. 

Purpose 

•  To  ensure  that  the  design  includes  all  characteristics  required  by  the  specialty  engineering  areas. 

•  To  serve  as  input  to  the  next  iteration  of  the  functional  analysis  (sec.  A2.2)  and  as  feedback  to 
design  studies  (sec.  A2.3.1.2)and  specifications  (sec.  A2.5. 1). 

Tools 

•  Mission  analysis,  life  cycle  cost,  etc.  programs  such  as  those  listed  in  Table  A-l. 

Inputs 

•  Functional  analyses. 

Outputs 

•  Feedback  to  design  studies  and  specifications. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Specialty  engineering  evaluation  is  performed  informally  during  the  CE/D 
and  CE/V  phases  and  formally  in  developing  specification  and  requirements 
verification  tasks  in  the  FSD  and  production  phases. 

Prerequisites:  Inputs  are  higher  level  functions  of  the  functional  analysis  (sec.  A2.2)  and 

concept  and  design  integration  data  (sec.  A2.3.1). 

Limitations,  Deficiencies,  Problems 

•  Available  tools  not  well  integrated. 

•  Available  tools  do  not  provide  adequate  data  management  capabilities. 

Associated  Military  Documents 

•  MIL-STD-499A,  Engineering  Management. 
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A2.4.1.4  Concept,  Design,  and  Operations  Assessment  Studies 

Description 

Concept,  design,  and  operations  assessment  studies  are  specialized  names  for  trade  studies  or 

specialized  studies  to  support  trade  studies. 

Purpose 

•  To  provide  a  rational,  traceable  basis  for  decisions. 

•  To  provide  input  to  trade  studies. 

Tools 

•  Mission  analysis,  life  cycle  cost,  etc.  programs  such  as  those  listed  in  Table  A- 1 . 

Inputs 

•  Figures  of  merit. 

•  Trade  studies. 

Outputs 

•  Assessments  that  can  be  used  in  future  trade  studies. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  The  assessments  are  performed  throughout  the  development  cycle  whenever 
additional  information  is  needed  to  determine  the  feasibility  of  a  concept  or 
design  and/or  to  aid  in  the  selection  of  the  concept  or  design  that  best  meets 
the  customer’s  requirements.  Conceptual  assessments  are  made  in  the  early 
phases  to  evaluate  concepts;  design  and  operating  assessments  are  performed 
as  needed  to  ensure  a  design  meets  the  customer’s  requirements  and  to  guide 
the  design  process. 

Prerequisites:  Inputs  to  these  assessments  are  analytic  models  and  simulations,  designs, 

measures  of  effectiveness,  tests,  and  specialty  engineering  analyses. 

Limitations,  Deficiencies,  Problems 

•  Available  tools  not  well  integrated. 

•  Available  tools  do  not  provide  adequate  data  management  capabilities. 
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A2.4.1.5  Support  System  Analyses 
Description 

Each  pustulated  concept  and  design  must  be  evaluated  for  its  effect  on  support  subsystems.  The  cost 
of  maintenance,  repair,  operator  training,  and  provision  of  consumables  during  the  life  of  the  system 
can  be  nearly  as  great  as  the  initial  procurement  cost.  Also,  the  operational  readiness  of  the  system 
depends  on  the  support  subsystem. 

Purpose 

•  To  ensure  that  the  effect  on  the  support  system  is  considered  during  the  evaluation  and  decision 
process  involving  concepts,  operation,  or  configurations  driven  by  mission  and  system 
requirements. 

•  To  perform  trade  studies  and  assessments  involving  support  system  concepts,  designs,  and 
operations. 

Tools 

•  Mission  analysis,  life  cycle  cost,  etc.  programs  such  as  those  listed  in  Table  A-l. 

Inputs 

•  Systems  engineering  definition  of  a  configuration. 

•  Logistics  support  analysis  (LSA). 

•  LSA  data  sheets. 

Outputs 

•  LSA  record  (documentation). 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Support  system  analyses  are  used  throughout  the  development  cycle  (secs. 

A2  4. 1.2  and  A2.4.1.4).  They  progress  from  concept  to  detailed  design 
configuration  as  the  program  progresses. 

Prerequisites:  Prerequisites  are  system  and/or  design  engineering  definition  of  the  operating 

concepts  of  configurations  to  be  supported  (sec.  A2.3.1). 

Limitations,  Deficiencies,  Problems 

•  Available  tools  not  well  integrated. 

•  Available  tools  do  not  provide  adequate  data  management  capabilities.  The  LSA  record  database 
is  not  readily  useable  by  design  engineers. 

Associated  Military  Documents 

•  MIL-STD-1388-1. 
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A2.4.2  Test  and  Evaluation 


A  comprehensive  test  program  is  required  to  evaluate  the  system  design,  ensure  integration  of  the 
system,  and  verify  compliance  with  specification  requirements.  Engineering  development  testing  is 
required  to  reduce  risk  and  evaluate  individual  concepts  and  subsystems.  Testing  is  the  primary 
means  of  ensuring  that  a  high-quality  product  is  produced. 

A2.4.2.1  Laboratory  and  Development  Tests 

Description 

Engineering  laboratory  and  development  testing  is  required  to  reduce  risk  and  to  develop  data  in 
support  of  design  and  analytical  trade  and  evaluation  studies.  This  testing  is  often  termed 
"engineering  test  and  evaluation”  when  performed  on  large  segments  of  the  system  or  the  whole 
system. 

Purpose 

•  To  support,  supplement,  confirm,  and/or  refine  analytical  data  and  predictions. 

•  To  assist  in  early  selection  of  design  concepts  and  approaches  and  develop  or  refine  test  techniques. 

•  To  verify  or  validate  design  approaches  and/or  probe  technology  limitations  and  define  areas 
requiring  further  development. 

•  To  provide  test  data  to  support  preliminary  design  activities  (sec.  A2.3.1 .2),  design  studies,  trade 
studies  (sec  A2.4. 1  2),  or  risk  assessment  (sec.  A2.4.3.2). 

•  To  provide  data  and  insights  for  selection  of  feasible  concepts  for  further  evaluation  and  study. 
Tools 

•  None  commercially  available 

Inputs 

•  Test  information  sheets. 

•  System-level  requirements. 

Outputs 

•  Test  data  to  support  and  substantiate  design  activities. 

•  Trade  studies  or  risk  assessment. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Laboratory  and  development  tests  are  used  during  the  CE/D  phase  in 
selecting  preferred  concepts  and  approaches.  They  may  also  be  used  by 
Design  in  later  program  phases  as  part  of  the  normal  design  and  development 
process. 

Prerequisite:  Initiation  of  conceptual  design  studies  per  section  A2  3  1 .2  is  prerequisite 

The  tests  may  also  be  performed  in  support  of  technology  assessments 
(sec  A2  3  11) 

Associated  Military  Documents 

•  DODD  5000.3,  Tests  and  Evaluations. 
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A2.4.2.2  Feasibility  Tests 
Description 

Feasibility  testing  is  used  to  prove  the  concepts  or  designs  on  which  system  feasibility  rests.  It  is  a 
major  feature  of  risk  management  and  the  basis  for  the  DOD  CD/V  phase.  Test  article  configuration 
should  be  developed  from  the  functional  analysis  requirements,  and  successful  testing  may  eliminate 
the  need  for  much  further  functional  analysis. 

Purpose 

•  To  identify  and  validate  preferred  technical  approaches,  including  identification  of  technical  risks 
and  feasible  solutions. 

•  To  provide  test  data  necessary  to- 

-  Validate  concepts  and  approaches  (sec.  A2.3.1.2). 

-  Select  a  preferred  concept  for  follow-on  development  (sec.  A2.4. 1.2). 

-  Define  follow-on  development  requirements  and  risks  (secs.  A2.2.1.2  and  A2  4.3.2). 

Tools 

•  None  commercially  available. 

Inputs 

•  System-level  requirements. 

Outputs 

•  Test  data  necessary  to  validate  concepts  and  approaches. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  The  primary  use  of  feasibility  tests  is  during  the  CD/V  phase.  Such  tests  may 
be  selectively  or  incrementally  used  during  the  CE/D  phase. 

Prerequisites:  Prerequisites  are  selection  of  major  candidate  concepts  through  the  study  and 

analysis  process  as  discussed  in  sections  A2.3. 1 . 1  through  A2.3  1.6  and 
development  of  engineering  test  models  (sec.  A2.3.1.4). 
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A2.4.2.3  Integration  Testing 
Description 

Integration  testing  is  used  to  find  and  fix  problems  as  the  system  is  built  up  into  a  whole.  Internal 
and  external  interfaces  are  verified,  and  effective  operation  of  the  system  elements  as  an  integrated 
system  is  demonstrated.  The  effectiveness  of  training  and  support  systems  is  also  demonstrated.  The 
accuracy  and  suitability  of  installation  and  checkout  procedures  and  equipment  and  readiness  for 
formal  verification  testing  are  determined. 

Purpose 

•  To  verify  the  integrity  of  the  design  selected  and  its  ability  to  meet  performance  requirements  bv 
verifying  the  validity  of  system  interfaces  and  effective  interaction  between  the  elements 

•  To  find  and  fix  problems  as  the  system  is  built  up  into  an  integrated  whole 

•  To  verify  that  design  and  development  of  the  system  have  met  all  conditions  prerequisite  to 
initiation  of  formal  verification  activities,  including  parts  fabrication  and  modification,  etc 

Tools 

•  None  commercially  available 

Inputs 

•  System-level  requirements. 

•  System  configuration. 

Outputs 

•  Test  data  that  verifies  that  system  design  and  development  have  met  system  level  requirements. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Integration  testing  is  normally  performed  during  the  FSD  phase,  although 
some  initial  increments  may  be  accomplished  prior  to  FSD  Some  planning 
must  also  be  done  to  support  FSD  proposals,  etc 

Prerequisites:  Baseline  set  of  system  requirements  (sec  A2.5  1)  and  a  system  configuration 

(sec  A2.5  2)  are  prerequisites. 

Associated  Military  Documents 

•  DODD  5000.3,  Test  arid  Evaluation 
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A2.4.2.4  Formal  Verification  and  Qualification  Testing 
Description 

Formal  testing  qualifies  CIs  for  production  and  verifies  that  the  system  complies  with  its 
procurement  specifications  and  is  ready  for  acceptance.  Rigorous  configuration  control  is  required 
and  test  articles  should  be  built  by  production  personnel  using  production  tools.  Testing  should 
include  the  support  subsystem  and  tryout  of  deliverable  technical  data.  If  multiple  production 
systems  are  to  be  delivered,  acceptance  testing  of  each  is  required. 

Purpose 

•  To  verify  the  design  and  the  fabrication  process  and  ensure  the  design  integrity  of  the  system  over 
the  specified  operational  and  environmental  range.  From  an  evaluation  and  decision  standpoint, 
preproduction  qualification  ensures  the  readiness  of  configuration  item  designs  for  production,  and 
verification  tests  verify  that  the  system  is  ready  for  deployment  or  delivery.  The  testing  provides  a 
baseline  for  acceptance  tests  and  for  introduction  of  system  changes.  Production  qualification  and 
verification  confirms  both  the  design  and  the  production  process. 

•  To  ensure  and  document  closeout  of  contractual  requirements.  This  is  extremely  critical.  Ongoing 
records  of  test  results,  completions,  and  acceptance  must  be  maintained  throughout  the  entire 
process,  including  an  agreed-to  evaluation  of  any  retests  required  as  a  result  of  approved  changes. 

Tools 

•  None  commercially  available 

Inputs 

•  Product  baseline 

•  Integration  testing. 

Outputs 

•  Test  data  that  verifies  the  design  and  functional  integrity  of  the  system 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Formal  testing  is  applicable  to  the  FSD  phase  and  production  and 

deployment.  It  has  an  especially  critical  role  in  the  transition  from  the  FSD 
phase  to  production. 

Prerequisites:  Product  baselining  per  section  A2.5  and  integration  testing  per  section 

A2.4  2.3  are  required. 

Associated  Military  Documents 

•  DODD  5000  3,  Test  and  Evaluation. 
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A2.4.2.5  Checkout  Procedures  Tryout 


Description 

Procedures  used  to  install  and  check  out  deliverable  systems  at  remote  locations  must  be  validated  by 
tryout.  Maximum  use  should  be  made  of  deliverable  maintenance  and  operating  procedures  and  of 
factory  functional  acceptance  procedures.  Tryout  during  installation  of  test  systems  is  the  most 
effective  method  of  validating  the  procedures.  Safety  of  equipment,  personnel,  and  surroundings  is 
the  primary  concern,  especially  for  weapon  systems,  but  the  efficiency  of  fieldwork  is  also  important. 

Purpose 

•  To  verify  and  debug  the  procedures  used  to  arrive  at  the  system  configuration  delivered  to  the  user 
for  operation.  Procedures  are  used  to  install  and  check  out  the  system  to  a  point  ready  for  delivery 
to  the  user. 

Tools 

•  None  commercially  available. 

Inputs 

•  Installation  and  checkout  requirements  analysis. 

•  Baseline  configuration. 

•  Preliminary  or  final  technical  orders  (maintenance,  etc  ). 

Outputs 

•  Verified  and  validated  checkout  procedures  and  technical  orders. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Validation  of  checkout  procedures  occurs  late  in  the  FSD  phase  and  early  in 
the  production  and  deployment  phase. 

Prerequisite:  Deployment  and  activation  functional  analysis  per  section  A2.2.2.8  is 

required,  as  is  the  product  (deployment)  baseline  per  sections  A2.5. 1  and 
A2  5.2. 
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A2.4.3  Program  Evaluation 

Program  evaluations  of  the  system  design  have  program  and  business  considerations  beyond  purely 
technical  evaluation  They  include  evaluation  by  the  customer  and  government  regulatory  agencies. 

A2.4.3.1  Life  Cycle  Cost  Analysis 

Description 

Life  cycle  cost  (LCC)  analysis  forecasts  the  total  ownership  cost  of  a  system,  including  development, 
acquisition,  operation,  and  retirement  It  provides  data  for  trade  studies  and  for  program  and 
customer  decisions.  When  completed,  an  LCC  optimization  produces  a  design  that  meets  the 
requirements  for  the  minimum  cost  over  its  lifetime.  It  is  also  possible  to  determine  the  sensitivity  of 
cost  to  various  parameters  This  could  help  show  the  possibility  of  realizing  great  gains  in  some  areas 
(performance,  repair  time,  etc.)  for  very  little  increase  in  total  cost. 

Purpose 

•  To  ensure  that  a  i  (  major  decisions  are  based  on  an  understanding  and  comparison  of  cost 
considerations  and  effect  on  the  program 

•  To  optimize  the  system  for  minimum  cost  over  the  expected  life  of  the  system.  This  can  be  done  at 
any  level  of  the  design,  hut  has  the  greatest  impact  at  the  system  level.  Changes  in  the  design  are 
more  easily  incorporated  into  the  design  at  the  system  level,  but  the  accuracy  may  suffer  When 
done  at  the  detailed  design  level,  the  cost  estimate  is  more  accurate  but  changes  in  the  design  are 
much  harder  to  make  because  of  the  cost. 

•  To  support  study  and  analysis  activities  and  technical  program  reviews  and  formal  audits  LCC 
reports  will  normally  be  a  contract  submittal  item,  either  in  support  of  or  as  part  of  trade  study- 
reports 

Tools 

•  Life  cycle  cost  programs.  RCA  PRICK 

•  CASA 

Inputs 

•  Baseline  system  description 

Outputs 

•  Documentation  of  all  phases  of  LCC  development,  procurement,  operation,  and  support. 

•  LCC  reports 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  LCC  analysis  is  applicable  to  all  phases  It  also  applies  to  all  changes  after  a 
Cl  (or  system)  is  formally  baselined. 

Prerequisite:  The  prerequisite  is  a  baseline  system  description  and/or  description  of 

alternatives. 

Limitations,  Deficiencies,  Problems 

•  Component  cost  data  becomes  obsolete  quickly 
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A2.4.3.2  Risk  Assessment 


Description 

Risks  must  be  assessed  and  managed  throughout  the  life  of  a  program.  Systems  engineering  methods 
are  specifically  designed  to  reduce  program  risk.  Risk  categories  are  technical  performance, 
management,  schedule,  cost,  logistics,  and  manufacturing  The  Defense  Science  Hoard  has  identified 
the  transition  from  PSD  to  production  as  a  major  program  risk,  which  can  he  alleviated  by  certain 
practices  during  system  development 

Purpose 

•  To  identify  and  assess  the  effect  of  risk  on  the  program  in  the  categories  of  technical  performance, 
management,  schedule,  cost,  logistics,  and  manufacturing. 

•  For  risks  having  potentially  serious  impact,  to  develop  recovery  and  workaround  plan.' 

Tools 

•  Program  evaluation  review  techniques  (PERT)-RISNET. 

•  Life  cycle  cost  model 

Inputs 

•  Conceptual  design. 

•  Risk  analysis  and  potential  problem  analysis. 

•  Risk  assessment. 

Outputs 

•  Risk  management  and  abatement  plan 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Risk  assessment  and  management  are  applicable  throughout  all  acquisition 
phases. 

Prerequisites:  Conceptual  design  studies  (sec.  A 2  3  1  2 )  are  prerequisite.  Risk  assessment  is 

interactive  with  studies  and  analyses  (sec.  A2. 4.1)  and  used  primarily  for 
program  management. 

Associated  Military  Documents 

•  MIL  STD  1521 B  Technical  Reviews  and  Audits  for  Systems,  equipments,  and  Computer  Software 
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A2.4.3.3  Technical  Program  Reviews  and  Formal  Audits 
Description 


r 


Technical  program  reviews  and  audits  are  major  milestones  in  system  development,  and  decisions  on 
proceeding  to  the  next  stage  of  work  hinge  on  a  successful  outcome.  System-level  reviews, 
emphasizing  integration  of  CIs  into  a  system,  are  held  upon  completion  of  the  Cl-level  preliminary 
and  critical  design  reviews. 

Purpose 

•  To  monitor  and  assess  the  technica1  progress  of  the  program,  with  emphasis  on  ensuring  that  the 
defined  requirements  are  complete  and  the  evolving  design  is  adequate  to  meet  them. 

•  To  assure  the  customer  and/or  management  that  the  program  is  progressing  in  a  satisfactory 
manner. 

•  To  serve  as  a  basis  for  deciding  to  proceed  with  the  program  or  make  corrections  or  adjustments 
deemed  necessary  or  desirable 

Tools 

•  None  commercially  available. 

Inputs 

•  System  baseline  (current). 

•  Preliminary  design  review. 

•  Critical  design  review 

Outputs 

•  Assurance  that  the  program  is  progressing  satisfactorily. 

•  Documented  output  for  decision  making. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Program  reviews  are  held  in  all  phases,  but  for  DOD  programs,  primarily  in 
the  later  part  of  the  CD/V  and  throughout  the  FSD  phases.  Initial  reviews 
during  early  phases  concentrate  on  identification  of  and  concurrence  in 
system  requirements.  The  level  of  detail  progresses  through  detailed 
hardware  and  software  design  reviews  and  configuration  audits.  Figure  1 
illustrates  the  reviews  and  audits  as  they  match  the  DOD  acquisition  system 
program  phases  and  shows  how  the  reviews  match  the  various  baselines. 

Prerequisites:  Prerequisites  depend  on  the  nature  and  type  of  review:  see  reference  4, 

chapter  12  for  guidance. 

Associated  Military  Documents 

•  MIL-STD-1521B, Technical  Reviews  and  Audits  for  Systems,  Equipment,  and  Computer  Software 
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A2.4.3.4  Environmental  Impact  Statement 
Description 

Many  state  and  federal  regulatory  agencies  require  special  studies  and  reports  even  fhv>ugh  the 
system  may  be  deployed  on  federally  owned  land.  For  non  government  customers,  there  is  even  more 
application.  Environmental  impact  statements  (EIS)  are  an  example  that  applies  wherever  new 
construction  or  operation  on  non-federally  controlled  land  is  planned.  Over-the-road  systems  must 
comply  with  state  highway  regulations  as  well. 

Purpose 

•  To  comply  with  the  National  Environmental  Policy  Act  of  1969  (NEPA)  as  implemented  by 
Executive  Orders  1 1514  and  11991  and  the  Council  on  Environmental  Quality  (CEQ)  regulations 
of  November  29,  1978 

•  To  ensure  compliance  with  both  the  letter  and  the  intent  of  the  law. 

•  To  help  public  officials  understand  environmental  consequences  and  make  decisions  that  result  in 
actions  that  protect,  restore,  or  enhance  the  environment. 

Tools 

•  None  commercially  available. 

Inputs 

•  Correlates  with  identification  of  facility  requirements  and  facility  criteria 

Outputs 

•  Environmental  impact  statement. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  The  EIS  is  applicable  in  varying  degrees  to  all  phases.  A  separate  EIS  may  be 
required  for  prototypes  or  other  special  tests  or  test  installations  at  the  system 
level. 

Prerequisite:  Mission  and  system  requirements  must  be  defined.  The  EIS  may  be  a  factor  in 

measures  of  effectiveness  and/or  system  constraints. 
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A2.5  BASELINE  FOR  NEXT  CYCLE 


A  baseline  must  be  established  to  begin  the  next  level  of  analysis  or  the  next  phase  of  a  program.  The 
baseline  documents  the  current  status  of  the  requirements  and  configuration,  the  requirement 
base'  ’ne  in  the  specification  set  and  the  configuration  baseline  in  a  set  of  drawings  and  documents  (or 
book-form  drawings) 

A2.5.1  Specification  Baseline 

Specifications  are  the  contractual  technical  definition  of  what  is  being  purchased,  what  it  must  do, 
how  well  it  must  do  it,  and  what  constitutes  proof  that  it  does  it.  From  the  purchaser's  viewpoint., 
they  define  a  baseline  of  what  is  being  purchased.  The  specifications  also  are  the  starting  point  for 
the  product  builder  and  a  unifying  reference  throughout  the  project.  From  a  systems  engineering 
viewpoint,  they  are  a  repository  of  the  performance  and  configuration  requirements  developed  during 
each  phase  and,  therefore,  a  product. 


A2.5.1.I  System  and  Segment  Specification 

Description 

If  not  furnished  by  the  customer,  a  system  specification  is  prepared  to  define  the  mission,  technical 

performance  requirements,  allocation  of  functions  to  the  next  level,  design  constraints,  system 

external  interfaces,  and  verification  requirements. 

Purpose 

•  To  document,  for  reference  in  the  contract,  the  technical  definition  of  the  system  and/or  segment 
mission,  performance  requirements,  and  constraints  on  fabrication  and  the  verification  required  to 
prove  specification  compliance. 

•  To  be  used  as  a  contractual  and  technical  baseline  for  the  next  phase  (sec.  A2. 1.2.5)  and  as  a  major 
communication  and  control  device  within  the  project. 

Tools 

•  None  commercially  available. 

Inputs 

•  System  requirements  allocation. 

•  Technic;  I  and  performance  requirements. 

»  Mission  analysis. 

Outputs 

•  System  and  segment  specification  baseline  for  the  next  phase. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  By  the  end  of  the  CE/D  phase,  the  system  and  segment  specifications  should 
be  sufficiently  complete  to  specify  all  system  functions,  overall  system 
performance  requirements,  and  functional  allocation  to  prime  or  critical 
items.  This  level  of  specification  is  identified  as  the  functional  baseline  after 
authentication  of  the  specification.  Expansion  and  revision  of  system 
functions  to  reflect  information  developed  during  the  CD/V  phase  plus  major 
quality  assurance  requirements  lead  to  the  system  and  segment  specifications 
that  are  part  of  the  allocated  baseline  (sec.  A2.5. 1 .2)  at  the  end  of  the  CD/V 
phase.  Further  completion  of  the  quality  assurance  requirements  and 
addition  of  top-level  part-number  configuration  identification  and  system 
production  acceptance  requirements  complete  the  system  and  segment 
specifications  by  the  time  of  the  CDR  du.ing  the  FSD  phase.  This  version  is 
part  of  the  product  baseline. 

Prerequisites:  Prerequisites  are  functional  allocation  (sec.  A2.2.1.2)  and  system 

requirements  analysis  and  allocation  (sec.  A2.2. 1 .3). 
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A2.5.1.2  Configuration  Item  Specifications 
Description 

A  development  Cl  specification,  containing  performance  requirements,  constraints,  and  verification 
requirements,  is  prepared  for  each  Cl  requiring  development.  A  product  specification,  containing 
reference  to  the  drawings  defining  the  configuration  qualified  for  production  and  production 
acceptance  requirements,  is  also  prepared  for  each  Cl. 

Purpose 

•  For  CIs  that  require  development,  to  document,  for  reference  in  the  contract,  the  technical 
definition  of  each  Cl’s  performance  requirements  and  constraints  and  the  verification  required  to 
prove  compliance  with  the  specification. 

•  To  be  used  as  the  contractual  and  technical  baseline  for  the  next  phase  (sec.  A2.1.2.5)  and  as  a 
major  communication  and  control  device  within  the  project  for  the  development  of  the  item. 

Tools 

•  None  commercially  available. 

Inputs 

•  System  requirements  analysis  and  allocation. 

•  Derived  requirements  allocation. 

•  Quality  assurance  requirements. 

•  MIL-STD-490A,  Specification  Practices. 

Outputs 

•  Cl  specifications. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Cl  B  specifications  may  be  prepared  during  the  CD/V  phase  for  prototypes  or 
test  articles;  however,  final  preparation  is  usually  completed  during  the  early 
FSD  phase.  The  C  specifications  are  prepared  late  in  the  FSD  phase,  to  be 
completed  when  the  design  qualification  is  completed.  The  B  specifications 
are  part  of  the  allocated  baseline,  and  the  C  specifications  are  part  of  the 
product  baseline. 

Prerequisites:  System  and  segment  specifications  (sec.  A2.5.1. 1),  functional  allocation  (sec. 

A2  2.1.2),  and  system  requirements  analysis  and  allocation  (sec.  A2.2.1.3)  are 
required. 

Associated  Military  Documents 

•  MIL-STD-490A  (Hardware). 

•  MIL-STD-483A  (Software). 
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A2.5.1.3  Commercial  Item  Documentation 


Description 

Commercial  (off-the-shelf)  hardware  and  software  and  items  already  in  the  military  inventory  must 
be  controlled  to  ensure  that  they  function  correctly  in  the  system,  operate  in  the  environment 
planned,  and  can  be  supported  for  maintenance  and  repair.  However,  the  cost  of  such  control  and 
testing  must  be  minimized.  Purchasing  a  vendor’s  specifications,  data  sheets,  test  reports,  and 
support  is  an  option. 

Purpose 

•  To  document,  for  procurement  and  reference  in  the  contract,  the  technical  definition  of  the 
commercial  item's  performance  and  the  verification  required  to  prove  compliance  with  the 
specification 

•  To  be  used  as  a  contractual  and  technical  baseline  for  the  next  phase  (sec.  A2. 1.2.5)  and  as  a  major 
communication  and  control  device  within  the  project. 

Tools 

•  None  commercially  available. 

Inputs 

•  System  and  segment  specifications. 

•  System  requirements. 

•  Functional  allocation. 

Outputs 

•  Documentation. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Documentation  for  items  that  will  not  be  developed  as  part  of  the  project  (eg., 
off-the-shelf  hardware)  should  be  complete  by  the  end  of  the  FSD  phase.  It 
becomes  a  part  of  the  product  baseline. 

Prerequisites:  System  and  segment  specifications  (sec.  A2  5.1.1),  functional  allocation  (sec. 

A2.2  1  2),  system  requirements  analysis  and  allocation  (sec.  A2.2.1.3),  and 
proper  operation  in  the  system. 

Limitations,  Deficiencies,  Problems 

•  Manual  preparation  of  documentation,  information  seldom  available  in  electronic  medium. 
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A2.S.2  Configuration  Baseline 

The  current  configuration  of  the  system  baseline  should  be  defined  and  updated  frequently  during 
development;  complete  documentation  is  required  at  the  completion  of  the  acquisition  phase.  A  full 
set  of  production  drawings  forms  establishes  the  configuration  baseline  for  the  CIs  composing  the 
system.  Supplementary  system-level  drawings,  indexes,  diagrams,  and  documents  are  required  to 
document  trainers,  support  systems,  facilities,  modification  kits,  etc.,  in  the  system  configuration. 

A2.5.2.1  System  Description  Document 

Description 

A  high-level  description  of  the  system  and  its  mission,  operation,  architecture,  and  configuration, 
with  references  to  defining  and  controlling  data,  is  an  excellent  integration  and  communication  tool. 
Because  the  system  description  document  is  not  a  legal  instrument  like  the  system  specification  and 
is  not  subject  to  Class  1  configuration  control  by  the  customer,  it  can  be  more  responsive  to  the  needs 
of  the  program  and  contain  short-term  information. 

Purpose 

•  To  provide  a  top-down  portrait  of  the  system  that  continuously  reflects  the  current  level  of 
definition  in  terms  of  capabilities  and  configuration. 

•  To  focus  the  systems  engineering  efforts  on  developing  and  documenting  the  design  of  the  system. 

•  To  ensure  timely  coordination  and  integration  of  the  system  engineering  activities  and  their 
interfaces  with  the  technologies,  design  (hardware,  software,  facilities),  logistics,  and  other 
specialties  and  disciplines. 

Tools 

•  None  commercially  available. 

Inputs 

•  Cl  production  drawings. 

•  Supplementary  system-level  drawings,  indexes,  diagrams,  and  documents. 

Outputs 

•  Configuration  identification  and  definition  document 

•  Configuration  control  document 

•  Configuration  status  accounting. 

•  Configuration  audits. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  The  system  description  document  should  define  the  system  design  status  at 
the  beginning  and  end  of  each  phase.  It  should  be  established  early  in  the 
CE/D  phase.  It  should  also  support  the  various  design  reviews,  with  special 
emphasis  on  formal  reviews  associated  with  the  functional,  allocated,  and 
product  baselines. 

Prerequisites:  Initiation  of  functional  analysis  activities  (sec.  A2.2  1.1)  and  concept  and 

design  integration  studies  (sec  A2  3  1  2). 
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A2.5.2.2  Functional  Block  Diagrams 
Description 

Functional  block  diagrams  are  schematic,  symbolic,  graphic  portrayals  of  the  system  or  subsystems 
that  provide  a  comprehensive  grasp  of  how  the  system  is  laid  out  and  operates.  Blocks  or  symbols 
may  be  used  to  represent  components.  The  diagrams  can  be  prepared  at  many  levels  of  detail  for 
differing  purposes  and  should  be  included  in  the  system  description  document. 

Purpose 

•  To  define  and  document  baseline  system  configurations. 

•  To  support  baselining  of  the  system  design  (sec.  A2.5.2.1). 

•  In  early  phases,  to  establish  and  identify  alternative  configurations  being  evaluated  or  studied. 

•  To  establish  or  divide  development  responsibilities  between  organizations  and  identify  functional 
interfaces. 

•  As  the  level  of  detail  increases,  to  guide,  coordinate,  and  integrate  the  development  of  the  detailed 
design,  including  system  schematics  that  translate  the  functional  and  logical  modular  diagrams  to 
the  actual  system  design. 

Tools 

•  ECAD/ECAE  schematic  capture  and  documentation  tools. 

Inputs 

•  System  configuration. 

•  Alternate  concepts. 

•  Functional  interfaces. 

Outputs 

•  Functional  block  diagrams  document. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Functional  block  diagrams  are  used  in  all  phases.  They  are  informally 

baselined  in  early  phases  to  coordinate  design  development  and  selection 
studies.  They  are  a  key  item  in  configuration  control  at  the  system  design 
level  in  later  phases 

Prerequisite:  Development  of  schematic  block  diagrams  during  synthesis  (sec.  A2  3  3  1  5)  is 

required 

Limitations,  Deficiencies,  Problems 

•  Distribution  and  management  of  diagrams  is  not  well  supported  across  the  available  systems. 
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A2.5.2.3  System  Interface  Definition 
Description 

The  external  interfaces  of  the  system  are  defined  as  part  of  the  baseline  to  reflect  any  changes  to  the 
system  requirements  (sec.  A2.1.2.4)  that  have  occurred  during  the  phase  and  to  provide  a  definition 
for  the  system  requirements  (sec.  A2.1.2.4)  of  the  next  cycle. 

Purpose 

•  To  identify,  coordinate,  and  control  system  interfaces  during  the  early  phases  of  study  and 
evaluation  leading  to  selection  and  development  of  the  preferred  system  design. 

•  To  provide  the  basis  for  development  of  formal  interface  control  data  (sec.  A2.5.2.8). 

•  To  preserve  system  integrity  as  the  design  evolves  through  identification  and  control  of  interfaces, 
both  internal  and  external,  with  respect  to  the  contractor’s  system  design  responsibilities. 

•  To  serve  as  a  basis  for  follow-on  preparation  of  interface  control  documents  (ICD). 

Tools 

•  None  commercially  available. 

Inputs 

•  System  requirements. 

•  Functional  block  diagrams  and  analyses 

Outputs 

•  Interface  control  drawings  for  interface  control. 

•  Interface  control  documents  for  the  working  group. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  The  system  interface  description  is  used  in  all  phases,  pending  development  of 
formal  ICDs 

Prerequisites:  Development  of  schematic  block  diagrams  during  synthesis  (sec.  A2  3  1  5)  is 

required. 

Associated  Military  Documents 

•  MIL  STD  483 
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A2.S.2.4  Software  Architecture 


Description 

Definition  of  the  software  architecture  in  the  baseline  documentation  is  necessary  to  ensure 
integration  of  the  system  design. 

Purpose 

•  To  integrate  the  development  of  software  into  the  total  system  design  as  it  progresses  through  a 
series  of  definable  configuration  baselines. 

•  To  support  baseline  definition  of  the  system  design. 

•  To  ensure  integration  of  system  requirements  and  software  design. 

Tools 

•  Computer-aided  Software  Engineering  tools. 

Inputs 

•  System  requirements. 

•  Software  design. 

Outputs 

•  Software  architecture  definition 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  The  software  architecture  generally  follows  and  correlates  with  the  functional 
allocation  (sec.  A2.2. 1.2). 

Prerequisite:  Development  of  block  diagrams  per  section  A2  3  1  5  is  required. 

Associated  Military  Documents 

•  DOD  STD  2167 
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A2.5.2.5  Documentation  of  Alternatives 


Description 

Alternatives  considered  and  evaluated,  as  well  as  alternatives  not  yet  resolved,  must  be  documented 
as  a  part  of  the  baseline  to  record  the  decision  process  leading  to  the  baseline. 

Purpose 

•  To  document  alternative  concepts  and  configurations  in  support  of  the  evaluation  and  decision 
function  (sec.  A2.4)  in  order  to  select  a  preferred  concept  or  configuration  for  development 

Tools 

•  MCAD  solid  and  wire  frame  modeling  tools. 

•  ECAD/ECAE  schematic  capture  and  documentation  tools. 

Inputs 

•  Selection  of  preferred  concept  or  configuration  for  development. 

Outputs 

•  Preferred  concept 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  During  early  phases,  it  is  used  to  select  system-level  concepts  and 

configurations.  It  may  be  applied  to  progressively  lower  levels  of  subsystems, 
configuration  items,  etc.,  as  the  program  progresses. 

Prerequisites:  Initial  mission  and  concept  studies  as  defined  in  section  A2.3  1  2  are  required. 

Limitations,  Deficiencies,  Problems 

•  Available  tools  have  limited  representation  and  analysis  capabilities. 

•  Available  tools  not  well  integrated 

•  Available  tools  do  not  effectively  address  all  data  management  and  documentation  needs. 
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A2.5.2.6  System  Schematics 
Description 

A  set  of  system  schematic  diagrams  should  be  prepared  and  included  in  the  baseline  after  the 
functional  block  diagrams  have  stabilized 

Purpose 

•  To  define  and  document  baseline  system  configurations  as  they  become  definite. 

•  To  coordinate  the  execution  of  the  detailed  hardware  and/or  software  design  and  ensure  that  the 
resulting  system  achieves  the  desired  operational  and  functional  integrity. 

•  Especially,  to  ensure  coordinated  and  timely  consideration  and  development  of  the  support  system 
and  its  elements  to  match  the  operational  system  design  as  it  evolves  or  is  modified. 

•  To  serve  as  a  key  element  in  validation  and  verification  of  system  design,  including  comparisons 
and  assessment  of  effects  between  test  and  production  configurations. 

Tools 

•  ECAD/ECAE  schematic  capture  and  documentation  tools 

Inputs 

•  Functional  block  diagrams. 

•  System  configuration 

•  System  functional  requirements  and  allocations. 

•  Interface  control  drawings. 

Outputs 

•  System  schematics  document. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  The  system  schematics  should  be  baselined  after  sufficient  system  definition 
and  prior  to  or  in  support  of  PDR  of  major  system  elements  Normally,  they 
will  be  baselined  during  the  FSD  phase  However,  on  some  programs  it  may 
be  desirable  to  establish  a  schematic  baseline  prior  to  FSD  (e  g  ,  to  support 
development  and  validation  activities  or  FSD  proposal  preparation). 

Prerequisite:  Block  diagrams  (sec.  A2  3  1.5)  are  required. 

Limitations,  Deficiencies,  Problems 

•  Available  tools  do  not  effectively  address  all  data  management  and  documentation  needs. 
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A2.5.2.7  Technical  Review  Data  Packages 
Description 


Data  to  be  reviewed  or  presented  at  formal  technical  reviews  is  collected  into  a  package  for  customer 
review  prior  to  the  meeting.  The  data  packages  are  retained  as  the  collected  baseline  at  the  time  of 
the  meeting. 

Purpose 

•  To  support  reviews  and  audits  and  obtain  technical  approval  and/or  direction. 

•  To  provide  documented  traceability  of  the  review  configuration,  resulting  approvals  and/or 
technical  direction,  and  follow-on  implementation  and  design  progression. 

Tools 

•  None  commercially  available. 

Inputs 

•  System  configuration  baseline. 

Outputs 

•  Data  package  to  support  technical  reviews  and  audits. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Technical  reviews  and  audits  are  normally  established  by  the  customer  and 
may  be  applicable  to  any  phase  The  primary  emphasis  is  during  the  CD/V 
and  FSD  phases.  Those  reviews  associated  with  the  functional,  allocated,  and 
product  baselines  are  emphasized. 

Prerequisites:  Specification  and  configuration  baselining  must  be  established  at  the 

appropriate  level  of  detail  to  support  the  type  of  technical  review  scheduled. 

Associated  Military  Documents 

•  MIL-STD-1521B,  Technical  Reviews  and  Audits  for  Systems,  Equipments,  and  Computer 
Software. 
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A2.5.2.8  Interface  Control  Drawings 
Description 

Designated  interfaces  are  controlled  by  interface  control  drawings  or  documents.  Controlled 
interfaces  should  include  those  with  external  systems,  between  different  products  of  contracts  with 
competitively  procured  products,  and  with  critical  internal  systems. 

Purpose 

•  To  establish  and  maintain  control  of  functional  and  physical  interface  characteristics  that  must 
remain  compatible  between- 

-  Two  or  more  elements  that  make  up  the  system. 

-  The  system  and  any  element  external  to  it,  including  facilities,  personnel,  etc. 

•  To  serve  as  part  of  the  system  configuration  baseline  and  support  technical  reviews. 

Tools 

•  None  commercially  available. 

Inputs 

•  System  definition  or  configuration  baseline. 

•  Functional  interface  characteristics  (electrical,  hydraulic,  pneumatic,  mechanical,  etc  ). 

•  Physical  interface  characteristics. 

•  Technical  reviews  by  interface  control  working  group  (ICWG). 

Outputs 

•  Interface  control  drawings  and  documents. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Normally  interface  control  drawings  are  applicable  during  the  FSD  and 

follow-on  production  phases.  They  become  part  of  the  configuration  control 
requirements  associated  with  finalizing  design  of  the  CIs  and  other  system 
elements  and  maintaining  the  integrity  of  the  system  design  through  final 
development  and  test.  They  are  also  critical  for  transition  from  the  FSD 
phase  to  production  and  deployment. 

Prerequisites:  Functional  block  diagrams  (sec.  A2.3.1.5). 

Associated  Military  Documents 

•  MIL  STD  483A,  Configuration  Management  Practices  for  Systems,  Equipments,  Munitions,  and 
Computer  Programs. 
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A2.5.2.9  Design  Drawings 
Description 

Released  design  drawings  define  and  control  the  configuration  of  the  electrical  and  mechanical 
components  of  the  system  and  their  assembly  and  installation.  Thus,  when  prepared,  they  are  a 
principal  element  in  the  system  configuration  baseline  and  supersede  earlier  baseline  data. 

Purpose 

•  To  document  in  an  identifiable  package  the  necessary  instructions  for  repetitively  translating,  as 
desired,  the  engineering  definition  into  the  product  defined;  includes  fabrication,  processing, 
assembly,  inspection,  and  acceptance  test  directions  and  procedures  as  necessary. 

•  To  obtain  technical  approval  of  design,  fabrication,  and  delivery  of  the  end  product 

•  To  permit  system  level  configuration  control 

looks 

•  KCAIVKCAK  schematic  capture  and  documentation  tools. 

Inputs 

•  System  configuration  or  baseline. 

•  Drawing  trees 

•  Design  requirements 

•  Performance  allocations. 

Outputs 

•  I'echnica!  approval  of  design  drawings 

•  Knahlingof  system  level  configuration  control  and  definition 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Baselined  drawings  are  primarily  applicable  to  the  FSD  and  production  and 
deployment  phases.  They  may  also  be  required  for  test  installations. 

Prerequisite:  Baselining  of  the  design  drawings  needs  to  follow  baselining  of  the  design 

requirements  and  performance  allocations  and  identification  of  design 
constrain'  =  This  is  normally  provided  via  the  Cl  specifications  (sec.  A4.5. 1.2). 

Limitations,  Deficiencies,  Problems 

•  Available  tools  do  not  effectively  address  all  data  management  and  documentation  needs 
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A2.5.2.10  Facilities  Criteria 


> 


Description 

Facilities  criteria  documentation  developed  during  design  synthesis  (sec.  A2  3.3  3)  must  he  included 

in  the  configuration  baseline. 

Purpose 

•  To  define,  in  terms  of  the  data  necessary  to  govern  construction  or  modification  inspection  and/or 
verification,  the  facilities  that  become  part  of,  interact  with,  or  support  the  baseline  system 

•  To  establish  a  basis  for  acceptance  of  facilities  and  for  coordinating  and  evaluating  changes 
involving  facilities. 

Tools 

•  N'one  commercially  available. 

Inputs 

•  Engineering  requirements. 

•  Manufacturing  requirements 

•  Operational  support,  test,  and  training  facilities 

•  Turnover  configuration 

Outputs 

•  Facilities  requirements  documents 

•  Facilities  criteria  document. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  For  facilities  that  function  a-  part  of,  or  are  necessary  to  support,  system 

operations,  baselining  of  requirements  at  a  high  level  may  start  early  in  the 
CF/I)  phase,  with  progressive  levels  of  detail  "baselined"  as  required  to 
support  development  of  system  elements.  The  verification  baseline  must  be 
established  at  a  point  that  ensures  that  facility  activation  supports 
installation,  assembly,  or  processing  of  system  elements  The  verification 
baseline  must  also  permit  ( 1 )  evaluation  and  disposition  of  any  discrepancies 
occurring  during  verification  and  (2)  determination  of  whether  any  re- 
verification  is  required  following  facility  modifications  On  programs 
involving  repetitive  processing,  verifications  required  prior  to  or  as  part  of 
each  processing  also  need  to  be  identified  and  baselined 

Prerequisite  s:  Definition  of  facility  requirements  and  interfaces 

Associated  Military  Documents 

•  MIL  STD-490A,  Specification  Practices 
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A2.5.2.11  Installation  Drawings 
Description 

System  assembly  or  installation  drawings  must  be  included  in  the  configuration  baseline.  The 
drawings  must  include  (by  reference)  assembly,  installation,  and  checkout  procedures.  Interim 
configurations  for  incremental  delivery  must  be  included.  Upon  completion  of  the  work,  provision 
must  be  made  to  update  the  baseline  to  reflect  the  as-built  configuration  if  trade  skills  are  involved 

Purpose 

•  To  establish  the  configuration  of  the  system  element  or  part  to  be  installed,  positioned,  and/or 

interconnected 

•  To  provide  necessary  instructions  for  its  installation,  including  instructions  for  inspection  and 
functional  tests  as  necessary  (by  inclusion  or  reference). 

•  To  define,  build,  and  deliver  the  end  product  to  the  customer  and  to  permit  system-level 
configuration  control.  As  a  secondary  function,  to  impose  configuration  control  on  Cl  production 
and  delivery. 

Tools 

•  MCA  D  solid  and  wire  frame  modeling  tools 

•  ECAD/ECAE  schematic  capture  and  documentation  tools. 

Inputs 

•  System  specification  and  system  description. 

•  System-level  test  configurations 

Outputs 

•  T-stala' .tier,  drawings 

•  "''"pport  for  installation  and  checkout  of  configuration  items  into  subsystems  and  systems. 

•  iliiingi  f system- level  configuration  control. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Installation  drawings  are  usually  baselined  near  the  end  of  the  FSD  pha  ?  or 
at  the  start  of  the  production  and  deployment  phase  They  may  be  required  for 
test  installations  during  earlier  phases.  They  apply  to  both  operating  and 
support  systems  and  installations 

Prerequisite:  Configuration  baseline  (sec  A2.5.2)  and  System  Interface  Definition  (sec 

A2  b  2.3) 

Limitations,  Deficiencies,  Problems 

•  Available  tools  not  well  integrated 

•  Available  tools  da  not  effectively  address  all  data  management  and  documentation  needs. 
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A2.5.2.12  Technical  Data 


Description 

The  technical  data  required  to  operate  and  maintain  a  system  must  be  delivered  concurrently  with 
the  system  increments.  A  tabulation  of  the  technical  data  must  be  considered  part  of  the 
configuration  baseline  of  the  system.  This  data  must  be  baselined  and  configuration  controlled  to 
match  hardware  and/or  software  configurations  and  changes  to  them. 

Purpose 

•  To  provide  manuals  and  instructions  for  training  personnel  and  operating,  maintaining,  or 
servicing  the  system  and  its  elements. 

Tools 

•  None  commercially  available. 

Inputs 

•  System  activation. 

•  Configuration  baseline 

Outputs 

•  Documentation  for  training  personnel  and  operating,  maintaining,  and  servicing  the  system. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Technical  data  is  usually  baselined  to  match  production  and  to  support 

deployment  and/or  initial  operational  test  and  evaluation  (10T&E).  It  may  be 
baselined  near  the  end  of  the  FSD  phase  or  partially  baselined  to  support 
system-level  testing  and  verification. 

Limitations,  Deficiencies,  Problems 

•  Available  data  preparation  and  management  tools  do  not  effectively  support  all  the  CALS  data 
management  and  documentation  needs. 

Associated  Military  Documents 

•  MIL-STD  38748B 
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A2.6  OTHER  SUPPORTING  TASKS  AND  ANALYSES 


Additional  analyses  are  used  in  designing  electronic  circuits  and  considered  to  support  the  basic 
design  process.  They  are  described  in  this  section. 

A2.6.1  Fault  Detection  and  Fault  Isolation 

Description 

Fault  detection  and  fault  isolation  (FD/Fl)  analyses  are  used  to  determine  the  effectiveness  of  the  test 
system  in  detecting  and  isolating  faults  in  electronic  circuits.  This  can  be  accomplished  in  several 
ways,  but  it  is  usually  a  manual  analysis  until  the  design  is  sufficiently  defined  to  employ  fault 
simulators  and  fault  graders. 

Purpose 

•  To  determine  the  effectiveness  of  the  fault  detection  and  fault  isolation  system,  measured  in  terms 
of  detection  coverage  and  the  number  of  items  to  which  a  failure  can  be  isolated. 

•  To  provide  data  for  the  creation  of  maintenance  documentation. 

Tools 

•  Design  rule  checkers. 

•  Fault  simulators  and  graders:  QuickFault,  Hi  Low  III,  SABER. 

Inputs 

•  System  description,  including  fault  detection  and  handling  provisions. 

•  Test  vectors 

•  Fault  dictionary  inputs. 

•  Failure  rates. 

Outputs 

•  Fault  dictionary. 

•  Fault  isolation  and  detection  statistics. 

•  Fault  detection  and  isolation  problem  areas. 

•  Detection  stimuli. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  A  system-level  FD/FI  analysis  should  be  completed  in  the  CE/D  phase  to 
ensure  adequate  fault  detection  and  containment  provisions  have  been 
incorporated  into  the  design.  The  analysis  should  be  refined  during  FSD 
detailed  design  with  the  aid  of  fault  simulators  and  graders. 

Limitations,  Deficiencies,  Problems 

•  Unless  abstract  or  simplified  fault  models  are  employed,  most  large  scale  designs  can  only  be 
simulated  in  sections  or  partially  simulated  due  to  their  size  and  complexity.  This  limitation 
increases  the  probability  that  integration  related  problems  will  not  be  found  until  breadboard  or 
prototype  testing 
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A2.6.2  False  Alarms 


Description 

False-alarm  analyses  are  used  to  determine  where  false  alarms  may  occur  and  the  probability  that  a 
fault  detection  system  will  report  nonexistent  errors. 

Purpose 

•  To  verify  that  the  false-alarm  rate  meets  requirements. 

•  To  provide  data  to  correct  any  problems. 

Tools 

•  None  commercially  available. 

Inputs 

•  System  description. 

•  Fault  detection  and  fault  isolation  design. 

•  Failure  modes  analysis. 

Outputs 

•  False-alarm  problems 

Phase  Application:  Should  be  conducted  as  part  of  the  Speciality  Engineering  Analyses  and 
E  valuations  (sec  A2  4.1  3)  during  CE/D  and  refined  during  FSD  detailed 
design. 

Prerequisite:  Design  drawings  and  knowledge  of  the  fault  detection  and  isolation  design 

provisions 
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A2.6.3  Functional  Verification 
Description 

Functional  verification  is  a  method  of  verifying  that  a  design  functions  according  to  the  design 
requirements.  It  involves  testing  the  functionality  of  the  design  against  the  requirements  to  check 
compliance. 

Purpose 

•  To  verify  that  the  functionality  of  electronic  designs  is  correct. 

•  To  find  any  problems  with  the  design. 

Tools 

•  Simulators:  QuickSim,  MSPICE,  SABER. 

Inputs 

•  System  and  circuit  descriptions. 

•  Test  vectors  or  stimuli. 

•  ROM  code  (if  any). 

•  PAL  code  (if  any). 

Outputs 

•  System  and  circuit  outputs. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  A  high-level  functional  analysis,  using  higher  level  models,  should  be 

conducted  during  systems  engineering.  This  analysis  should  be  refined  during 
FSD  detailed  design  by  the  circuit  design  engineer. 

Limitations,  Deficiencies,  Problems 

•  Unless  abstract  or  simplified  fault  models  are  employed,  most  large  scale  designs  can  only  be 
simulated  in  sections  or  partially  simulated  due  to  their  size,  complexity,  and  the  mix  of  analog  and 
digital  circuitry  This  limitation  increases  the  probability  that  integration  related  problems  will 
not  be  found  until  the  breadboard  or  prototype  testing. 

•  Functional  design  errors,  mode  switching,  and  other  problems  may  not  be  uncovered  until  late  in 
the  design  cycle  because  the  time  to  simulate  a  complete  mission  is  usually  prohibitive. 
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A2.6.4  Testability  Analysis 
Description 

A  high  level  testability  analysis  is  used  to  develop  a  high  level  test  plan,  determine  whether  the 
system-level  testability  requirements  can  be  met,  to  identify  areas  of  the  design  that  are  not  easily 
tested,  and  to  establish  BIT/BITE  resource  allocations. 

Purpose 

•  To  verify  that  the  system-level  testability  requirements  can  be  met. 

•  To  develop  a  high  level  test  plan  and  BIT/BITE  allocations. 

•  To  suggest  ways  of  improving  the  testability  of  the  design. 

Tools 

•  Design  rule  checkers. 

•  Fault  simulators  and  graders:  QuickSim,  QuickFault,  SABER,  Copter. 

Inputs 

•  System  and  circuit  description. 

•  Operational  modes. 

Outputs 

•  Testability  statistics  (e  g  ,  percent  fault  isolation  and  detection,  ambiguity  statistics). 

•  Testability  problem  areas. 

•  Suggestions  for  increasing  the  testability  of  the  design. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  A  high  level  testability  analysis  should  be  conducted  as  part  of  the  Speciality 
Engineering  Analysis  and  Evaluations  (sec.  A2.4.1.3)  during  CE/D  and 
refined  during  FSD  detailed  design.  The  analysis  can  be  initiated  once 
system-level  functional  block  diagrams  and  flows  have  been  established  and 
should  be  performed  prior  to  the  Test  and  Evaluation  task  (sec.  A2.4.2). 

Limitations,  Deficiencies,  Problems 

•  Available  tools  are  not  sufficiently  robust  for  large  scale  designs. 

•  Analysis  of  simulator  results  is  manual  and  time  consuming. 

•  Existing  tools  do  not  provide  the  needed  data  management  and  documentation  capabilities. 
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A3.0  DETAILED  DESIGN 


A3.1  FUNCTIONAL  ANALYSIS  AND  ALLOCATION 

Functional  analysis  identifies  the  characteristic  action  to  be  performed  by  each  functional  element  in 
the  design  and  the  performance  requirement  for  each  function  to  the  level  of  detail  required  to 
initiate  detailed  design  and  specify  required  performance  for  each  Cl  and  position.  Each  function 
identified  is  then  allocated  to  a  specific  circuit  or  circuit  board,  to  break  up  the  design  into 
manageable  parts  that  can  be  easily  designed. 

A3.1.1  Functional  Analysis 

Description 

A  refinement  of  the  Systems  Engineering  functional  analysis  (sec.  A2.2). 

Purpose 

•  To  identify  and  decompose  the  system-level  functional  description  of  the  end-item  function  in  a 
methodical,  disciplined  analysis 

•  To  provide  traceabilitv  of  the  system  and  mission  objectives  and  requirements  to  hardware  and 
software  elements. 

Tools 

•  Specification  and  rer  jirements  capture  tools:  RDD100  (Ascent  Logic) 

Inputs 

•  Functional  specificat  ons  and  requirements  at  the  Cl  level. 

•  Draft  Cl  specifications,  part  2 

•  Block  diagrams 

•  ICDs  between  boards  and  functions,  depending  on  level. 

Outputs 

•  Characteristics  of  board  subfunctions. 

•  Interrelationships  be  ween  subfunctions. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Functional  analysis  for  Detailed  Design  is  performed  jointly  by  the  Systems 
Engineering  and  Detailed  Design  groups.  It  should  be  initiated  prior  to  and 
performed  in  conjunction  with  functional  allocation  (sec.  A3. 1.2)  and  should 
precede  preparation  of  the  final  specifications  at  each  level 

Prerequisites:  System-level  baseline  (sec  A2  5)  definition  to  the  LRU  or  LRM  level. 

Limitations,  Deficiencies,  Problems 

•  Available  tools  not  sufficiently  robust  for  large  scale  programs. 

•  Available  tools  not  integrated  with  existing  electronic  design  systems. 

•  Available  tools  do  not  effectively  address  all  data  analysis,  management,  and  documentation 
needs. 
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A3. 1.2  Functional  Allocation 


Description 

Functional  allocation  for  Detailed  Design  should  be  a  refinement  of  the  Systems  Engineering 
functional  allocations  (sec.  A3. 1.2).  Each  function  generated  by  the  system-level  functional  analysis 
is  allocated  to  hardware  or  software  elements  (CIs,  components,  modules),  personnel  and  procedures, 
external  systems,  or  logistics  support  subsystems  via  the  system  hierarchy  (segments,  elements, 
subsystems,  etc.).  An  accounting  of  the  allocation  and  rationale  is  maintained. 

Purpose 

•  To  allocate  required  system  and  end-item  functions  to  functional  areas,  hardware  and  software 
elements,  personnel,  procedural  controls,  external  interfaces,  or  maintenance  and  support  logistics 
subsystems. 

•  To  maintain  an  accounting  of  the  allocations  made. 

Tools 

•  Specification  and  requirements  capture  tools:  RDD100  (Ascent  Logic). 

Inputs 

•  System-level  functional  block  diagrams  and  flows. 

•  System  and  mission  requirements. 

Outputs 

•  Functional  allocations. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Functional  allocation  for  Detailed  Design  is  performed  jointly  by  the  Systems 
Engineering  and  Detailed  Design  groups.  It  should  be  performed  in  parallel 
with  a  functional  analysis  at  the  circuit  board  level  (sec.  A3. 1.1)  and  should 
precede  preparation  of  final  specifications. 

Prerequisites:  Systems  Engineering  functional  allocations  to  the  LRU  or  LRM  level  (sec. 

A3. 1.2). 

Limitations,  Deficiencies,  Problems 

•  Available  tools  not  sufficiently  robust  for  large  scale  programs. 

•  Available  tools  not  integrated  with  existing  electronic  design  systems. 

•  Available  tools  do  not  effectively  address  all  data  analysis,  management,  and  documentation 
needs. 
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A3.2  DESIGN  SYNTHESIS 


Detailed  design  alternatives,  test  procedures,  and  detailed  specifications  are  defined  that  meet  the 
system  and  Cl  specifications  and  requirements. 

A3.2.1  Design  Development 

The  tasks  described  in  this  section  produce  the  actual  design.  The  system  and  Cl  specifications  and 
requirements  are  evaluated  and  detailed  design  alternatives  are  evaluated  until  the  design  either 
satisfies  the  specifications  and  requirements  or  it  is  determined  that  the  specifications  and 
requirements  can  not  be  met. 

A3.2.1.1  Hardware  and  Software  Interface  Definition 
Description 

Interfaces  between  individual  circuit  boards  and  board  subfunctions  are  derived  and  documented.  A 
preliminary  cut  at  the  board  interfaces  based  upon  system-level  considerations  is  used  as  a  baseline 
until  more  detailed  circuit  level  requirements  can  be  identified.  Functional  analyses  and  allocations 
at  the  circuit  board  level  determine  the  board  interfaces. 

Purpose 

•  To  produce  an  interface  specification  to  ensure  that  all  separate  parts  of  the  design  are  built  to  the 
same  specification  and  that  the  system  maintains  its  integrity  as  the  design  evolves. 

•  To  serve  as  a  basis  for  follow-on  preparation  of  ICDs. 

Tools 

•  None  commercially  available. 

Inputs 

•  System  functional  block  diagrams,  flows,  and  allocations  to  circuit  level. 

•  Characteristics  of  board  subfunctions. 

•  Interrelationships  between  subfunctions 

Outputs 

•  Interface  definition  for  each  major  design  element  (e  g.,  LRU,  LRM,  circuit  board  function, 
software  module). 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Although  initiated  after  the  functional  analyses  and  allocations,  it  is 
performed  in  conjunction  with  these  analyses. 

Prerequisites:  Baseline  system  configuration,  trade  factors  from  the  system  level  trade 

studies  (sec.  A2  4.1,2),  and  the  results  of  the  engineering  speciality  analyses 
(sec.  A2.4.1.3).  Detailed  functional  block  diagrams  and  allocations  at  the 
circuit  board  level  (sec.  A3.1). 
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A3.2.1.2  Trade  Studies 


Description 

Trade  studies  are  conducted  during  detailed  design  to  identify  and  evaluate  design  alternatives  at  the 
circuit  board  level.  A  trade  study  may  be  conducted,  for  example,  to  determine  which  of  several 
alternative  components  or  circuit  implementations  best  meets  the  applicable  Cl  requirements  and 
specifications.  Trade  studies  in  support  of  detailed  design  are  usually  not  formal  studies  and  often 
involve  data  from  existing  designs. 

Purpose 

•  To  determine  the  best  design  methodology,  circuitry,  and  components  to  use  in  the  design. 

•  To  find  the  design  alternative  which  best  satisfies  the  requirements  and  specifications. 

Tools 

•  None  commercially  available 

Inputs 

•  Characteristics  of  board  subfunctions. 

•  Interrelationships  between  subfunctions. 

•  LRU  and  board  specifications  and  requirements. 

•  Draft  Cl  specifications,  part  2,  block  diagrams. 

•  Budgets  for  power,  reliability,  performance,  etc. 

•  Data  from  previous  evaluations  of  design  alternatives  (functional  tests,  timing,  electrical, 
reliability,  thermal,  layout,  FMA,  etc.) 

•  Packaging  and  board  specifications. 

Outputs 

•  Preliminary  circuit  schematics. 

•  Circuit  function. 

•  Block  diagrams. 

•  Theory  of  operation. 

•  ICDs 

•  Circuit  specifications. 

•  Programmer  manuals. 

•  Throughput  analyses. 

•  Detailed  design  information. 


A3.2.1.2  Trade  Studies  (concluded) 


Where  It  Fits  in  the  Design  Process 

Phase  Application:  Trade  studies  are  conducted  throughout  detailed  design  to  identify  and  select 
design  elements  (LRUs,  LRMs,  circuits,  and  components)  which  best  meet  the 
Cl  specification. 

Limitations,  Deficiencies,  Problems 

•  Existing  design  optimization  methods  and  programs  are  not  sufficiently  robust  for  large  scale, 
complex  design  problems. 

•  Due  to  a  variety  of  factors  (for  example,  budget,  resource,  and  time  constraints;  lack  of  tools  to 
facilitate  trade  studies),  the  cost  (in  terms  of  budget,  schedule,  etc.)  of  conducting  trade  studies 
precludes  their  use  in  all  but  the  most  critical  situations. 

•  The  selection  of  the  "best”  design  alternative  from  among  several  is  often  based  on  a  consideration 
of  a  limited  number  of  parameters,  those  most  readily  accessible  to  or  familiar  to  designer. 
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A3.2.1.3  Design  Alternatives 
Description 

Schematics,  block  diagrams,  and  other  relevant  data  must  be  produced  to  document  the  design 
alternatives  considered  during  Detailed  Design  Any  packaging  and  layout  constraints,  such  as 
maximum  signal  path  lengths  or  components  that  must  be  placed  close  together  on  board,  must  be 
documented.  This  is  the  last  step  in  design  synthesis  and  produces  a  design  at  the  component  level 

Purpose 

•  To  produce  the  detailed  design  schematics  and  data. 

Tools 

•  MCAD  solid  and  wire-frame  modeling  tools. 

•  ECAD/ECAE  schematic  capture  and  documentation  tools. 

Inputs 

•  Preliminary  circuit  schematics. 

•  Circuit  function. 

•  Block  diagrams. 

•  Theory  of  operation. 

•  ICDs. 

•  Circuit  specifications 

•  Packaging  and  board  specifications 

Outputs 

•  Circuit  schematics. 

•  Circuit  function 

•  Block  diagrams. 

•  Theory  of  operation. 

•  ICDs. 

•  Circuit  specifications. 

•  Programmer  manuals. 

•  Throughput  analyses. 

•  Released  drawings. 

•  Detailed  design  information 

•  Packaging  and  layout  constraints. 

•  Parts  lists. 
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Where  It  Fits  in  the  Design  Process 

Phase  Application:  This  task  produces  the  final  design  data  from  all  previously  produced 
specifications  and  requirements. 

Limitations,  Deficiencies,  Problems 

•  Available  tools  not  well  integrated. 

•  Available  tools  do  not  effectively  address  all  data  management  and  documentation  needs. 
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A3.2.2  Design  Verification 

Design  verification  is  the  task  of  ensuring  that  all  each  Cl  in  a  design  meets  all  applicable  system 
requirements  and  specifications.  Design  elements  which  do  not  meet  the  applicable  requirements 
and  specifications  may  be  redesigned  if  the  degree  of  non-compliance  is  determined  to  be 
unacceptable.  The  major  product  of  this  task  is  documentation  demonstrating  the  compliance  of 
individual  Cls. 

A3.2.2.1  Test  Procedures  Development 
Description 

Test  procedures  must  be  developed  to  verify  design  compliance,  for  manufacturing  passoff,  and  for 
field  maintenance.  Although  the  tests  are  developed  to  exercise  as  much  of  the  design  as  possible,  the 
tests  are  customized  for  each  use  and  may  differ  greatly.  Manufacturing  tests  focus  on  quality  control 
issues  while  maintenance  tests  must  efficiently  detect  and  isolate  failures  that  occur  in  the  field. 

Typically,  manufacturing  tests  need  not  be  the  size  and  complexity  of  maintenance  tests  since  they 
need  to  only  sample  the  functionality  of  the  manufactured  item  to  verify  it  has  been  manufactured 
correctly. 

Purpose 

•  To  develop  test  procedures  and  stimuli  for  design  compliance,  manufacturing,  and  field 
maintenance. 

Tools 

•  None  commercially  available. 

Inputs 

•  Circuit  schematics 

•  Circuit  function. 

•  Block  diagrams. 

•  Theory  of  operation 

•  Circuit  specifications. 

•  Programmer  manuals. 

•  LRU  and  board  specifications  and  requirements  for  design  and  testing. 

Outputs 

•  Test  procedures. 

•  Test  stimuli. 

•  Expected  results  of  tests. 

•  Areas  of  design  that  cannot  be  tested . 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  This  task  is  performed  during  the  detailed  design  phase.  It  can  be  started  as 
soon  as  preliminary  schematics  are  available. 
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Limitations,  Deficiencies,  Problems 

•  Test  development  is  a  manual,  time  consuming  task  The  time  and  resources  needed  to  develop 
adequate  tests  for  a  design  a.  a  typically  underestimated,  particularly  if  the  circuit  has  not  been 
designed  to  be  testable  from  the  onset, 

•  Automatic  test  pattern  generation  iATPG)  is  not  feasible  for  most  current,  large-scale  designs  due 
to  their  size  and  complexity.  ATPGdoes  not  work  well  for  micioprocessor  based  designs 

•  t\  high  level  of  fault  detection  and  isolatin'-  is  difficult  to  achieve  and  verify 


A3.3 TECHNICAL  EVALUATION  AND  DECISION 


The  design  is  evaluated  to  check  for  conformance  to  the  specifications  and  requirements.  The  design 
are  analyzed  and  problems  are  corrected  or  allowed,  based  on  their  severity  and  the  cost  affixing 
them. 

A3.3.1  Electrical  Stress 
Description 

Electrical  stress  analysis  is  used  to  find  power  dissipation  and  current  requirements  of  electronic 
components.  This  data  is  used  to  predict  component  reliability 

Purpose 

•  To  find  the  power  dissipation  of  electronic  devices  in  order  to  determine  the  effects  on  the 
reliability  of  the  device 

Tools 

•  ECAD  simulation  tools:  MSPICE. 

Inputs 

•  Detailed  circuit  description 

•  Device  specifications. 

•  Operational  data. 

Outputs 

•  Power  dissipation  for  components 

•  Electrical  stress  for  components. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  This  analysis  is  performed  during  the  CD/V  and  PSD  phases  by  the  detailed 
design  engineers  once  detailed  circuit  diagrams  are  available 

Limitations,  Deficiencies,  Problems 

•  Most  current  designs  can  only  be  simulated  in  sections  or  in  part  due  to  their  size  and  complexity 
and  their  mix  of  analog  and  digital  circuitry.  Analysis  of  the  results  is  manual  and  time 
consuming. 

•  Device  models  for  custom  circuit  elements  are  often  not  available  due  to  proprietary,  resource,  or 
scheduling  reasons 

•  Available  simulators  do  not  effectively  add’  ess  all  data  management  and  documentation  needs. 
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A3.3.2  Fault  Detection  and  Fault  Isolation 


Description 

Ideally  these  analyses  should  be  a  continuation  of  the  fault  detection  and  isolation  (FD/FI)  analyses 
initiated  during  Systems  Engineering  (sec.  A2.6. 1).  The  analyses  are  used  to  assess  the  effectiveness 
of  the  provisions  incorporated  in  the  design  to  detect  and  isolate  faults  in  the  system  and  in  individual 
CIs.  The  analysis  is  usually  performed  on  individual  circuits  with  the  aid  of  a  fault  simulator  and  a 
set  of  test  vectors. 

Purpose 

•  To  determine  the  effectiveness  of  the  system’s  fault  detection  and  fault  isolation  capabilities, 
measured  in  terms  of  detection  coverage  and  the  number  of  items  to  which  a  failure  can  be  isolated. 

•  To  provide  data  for  the  creation  of  maintenance  documentation. 

Tools 

•  Fault  simulators  and  graders:  QuickFault,  Hi  Low  III,  SABER 

Inputs 

•  Circuit  description. 

•  Test  vectors 

•  Fault  list 

•  Failure  rates. 

Outputs 

•  Fault  dictionary. 

•  Detection  list 

•  Detection  stimuli. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Fault  detection  and  isolation  (FD/FI)  analyses  should  be  performed  during  the 
CD/V  and  FSD  phases  by  design  engineers. 

Limitations,  Deficiencies,  Problems 

•  Most  current  designs  can  ot.I,,  be  simulated  in  sections  or  in  part  due  to  their  size  and  complexity 
and  the  mix  of  analog  and  digital  circuitry.  Analysis  of  the  results  is  manual  and  nme  consuming 

•  Device  models  for  custom  circuit  elements  are  often  not  available  due  to  proprietary,  resource,  or 
schedule  reasons 

•  Available  simulators  do  not  effectively  address  all  data  management  and  documentation  needs. 
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A3.3.3  False  Alarms 


Description 

False-alarm  analyses  are  used  to  ensure  that  the  fault  detection  provisions  incorporated  into  a  design 
will  not  result  in  a  incidence  of  false  alarms  (false  indications  of  faults  or  errors)  greater  than  that 
permitted  by  the  system  or  Cl  specification. 

Purpose 

•  To  verify  that  the  false-alarm  rate  meets  requirements. 

•  To  provide  data  to  correct  any  problems. 

Tools 

•  None  commercially  available. 

Inputs 

•  Circuit  description 

•  Description  of  the  fault  detection,  isolation,  and  report  provisions. 

•  Fault  detection  and  isolation  statistics. 

•  Failure  modes  analysis  results. 

Outputs 

•  Problem  areas. 

•  False-alarm  rate. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  This  analysis  should  be  performed  during  the  CD/V  and  FSD  phases  by  the 
detailed  design  engineers  once  detailed  test  procedures  have  been  defined 
(sec.  A3. 3. 1)  and  a  fault  detection  and  isolation  analysis  (sec.  A3. 3. 2). 

Prerequisite:  Circuit  schematics  and  system-level  knowledge  of  the  fault  detection,  fault 

isolation,  and  fault  reporting  provisions. 

Limitations,  Deficiencies,  Problems 

•  Manual  and  time  consuming  task,  often  not  performed  until  physical  design  is  complete. 
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A3.3.4  Functional  Verification 


Description 

F  unctional  verification  is  a  method  of  verifying  that  each  element  of  the  design  and  the  design  as  a 
whole  functions  according  to  the  Cl  and  system  specifications.  The  functionality  of  each  individual 
circuit  is  simulated  and  individual  CIs  and  segments  are  tested  to  check  compliance. 

Purpose 

•  To  verify  that  the  functionality  of  an  electronic  design  is  correct. 

•  To  identify  areas  of  the  design  not  satisfying  the  specification. 

Tools 

•  Simulators:  QuickSim,  MSPICE,  SABER. 

Inputs 

•  Circuit  description. 

•  Test  vectors  or  stimuli. 

•  ROM  code  (if  any). 

•  PAL  code  (if  any). 

Outputs 

•  Circuit  outputs. 

•  Problem  areas. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  F unctional  verification  is  usually  performed  during  the  detailed  design 
process  by  the  circuit  designer  It  is  also  possible  to  perform  high-level 
functional  analysis,  using  higher  level  models,  during  the  systems 
engineering  phase. 

Limitations,  Deficiencies,  Problems 

•  Due  to  their  size  and  complexity  and  the  mix  of  analog  and  digital  circuitry,  current  designs  can 
only  be  simulated  in  sections  or  in  part.  Integration  problems  are  often  not  discovered  until 
breadboard  or  prototype  testing 

•  Functional,  mode  switching,  and  other  problems  may  not  be  found  because  designs  are  not  usually 
simulated  over  a  complete  mission  cycle  due  to  the  length  of  time  required  to  complete  such  a 
simulation  run. 
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A3.3.5  Loading  Analysis 
Description 

An  overloaded  device  may  not  be  able  to  drive  the  connected  inputs  to  a  particular  level  or  be  able  to 
change  output  levels  fast  enough.  This  can  create  logic  or  functional  errors  in  the  circuit,  affecting 
the  circuit's  functional  reliability.  To  prevent  these  problems,  components  are  derated  so  that  the 
maximum  loading  that  can  be  used  is  less  than  the  physical  maximum.  This  gives  a  margin  of  safety 
in  the  design  so  that  loading  of  components  is  not  pushed  to  the  limit,  creating  problems. 

Purpose 

•  To  calculate  the  load  driven  by  each  component  output  within  a  circuit  to  determine  the  effect  of 
loading  on  the  functional  reliability  of  the  device. 

•  DC  loading  analysis:  to  determine  the  fanout  of  each  output  and  its  effect  on  the  output’s  ability  to 
drive  to  the  needed  output  level. 

•  AC  loading  analysis:  to  determine  the  capacitive  loading  on  each  output  to  determine  effects  on 
timing. 

Tools 

•  Loading _ Analysis  (DC  only). 

Inputs 

•  Detailed  circuit  description  (parts  list  and  connection  list). 

•  Device  specifications. 

•  Interface  specifications. 

•  Derating  factor 

Outputs 

•  Loading  of  all  outputs  of  each  device  in  the  circuit. 

•  Output  loads  exceeding  derated  specifications. 

Where  It  Fits  in  the  Design  Process. 

Phase  Application:  This  analysis  is  should  be  performed  during  the  CD/V  phase  and  refined 
during  the  FSD  detailed  design  phase. 

Limitations,  Deficiencies,  Problems 

•  Due  to  their  size  and  complexity  and  the  mix  of  analog  and  digital  circuitry,  current  designs  can 
only  be  analyzed  in  sections  or  in  part.  Integration  problems  are  often  not  discovered  until 
breadboard  or  prototype  testing 
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A3.3.6  Preliminary  Layout 
Description 

Preliminary  layout  of  components  on  the  board  identifies  initial  board  sizing  requirements, 
placement  problems,  testability,  and  other  information  that  can  help  prevent  downstream  problems. 
This  data  can  also  be  used  in  performing  preliminary  thermal  analysis  for  reliability. 

Purpose 

•  To  establish  a  preliminary  physical  layout. 

•  To  enable  spatial,  routability,  thermal,  electrical,  mechanical,  reliability,  testability, 
maintainability,  and  environmental  requirements  to  be  evaluated  early  in  the  design  process, 
when  changes  can  be  made  to  optimize  the  design. 

Tools 

•  ECAD  PWB  design  systems:  Mentor  Package  and  Board  Stations,  Intergraph  system. 

Inputs 

•  Circuit  description. 

•  Parts  list. 

•  Board  description. 

•  Layout  requirements. 

•  Electrical  requirements. 

•  Design  rules,  military  specification  requirements. 

Outputs 

•  Preliminary  layout. 

•  Design  input  to  Package  Station  thermal  capability. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Preliminary  layout  is  performed  during  the  CD/V  phase  to  estimate  board- 
level  requirements  for  the  package  design.  It  is  also  performed  during  the 
detailed  design  phase,  when  complete  part  data  is  available  for  defining  the 
board-level  requirements  of  the  package  design. 

Limitations,  Deficiencies,  Problems 

•  Existing  tools  do  not  provide  the  needed  data  management  and  documentation  capabilities. 
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A3.3.7  Testability 

A  detailed  testability  analysis  is  used  to  allocate  testability  resources  within  the  CIs  and  LRUs, 
assess  the  testability  of  the  design,  and  to  ensure  that  the  testability  requirements  called  out  in  the 
system  and  Cl  specifications  have  been  met. 

Purpose 

•  Determine  and  assess  the  testability  of  each  Cl  based  on  testability  evaluations  of  individual 
design  elements  (e  g.,  circuit  boards,  circuits,  components). 

•  To  suggest  ways  of  improving  the  testability  of  individual  CIs,  LRUs,  and  circuit  boards. 

Tools 

•  Design  rule  checkers. 

•  Simulators  and  fault  graders:  MSPICE,  QuickSim, Copter. 

Inputs 

•  Circuit  description. 

•  Physical  layout. 

•  Operational  modes. 

Outputs 

•  Testability  rating. 

•  Areas  of  circuit  that  are  not  easily  testable. 

•  Suggestions  for  increasing  the  testability. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  This  analysis  should  be  performed  during  the  CD/V  phase.  A  detailed 

testability  analysis  should  be  performed  once  detailed  circuit  diagrams  are 
available.  . 

Limitations,  Deficiencies,  Problems 

•  Available  tools  are  not  sufficiently  robust  for  large  scale  designs. 

•  Analysis  of  simulator  and  fault  grader  results  is  manual  and  time  consuming. 

•  Existing  tools  do  not  provide  the  needed  data  management  and  documentation  capabilities. 
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A3.3.8  Worst  Case  Timing  and  Critical  Path  Analysis 
Description 

Worst  case  timing  and  critical  path  analyses  are  used  to  determine  whether  any  paths  in  an 
electronic  design  have  or  could  have  timing  problems.  Timing  problems  can  be  caused  by  such  things 
as  variations  between  components,  temperature,  radiation,  etc. 

Purpose 

•  To  determine  timing  problems  in  the  circuit  due  to  variations  in  the  timing  of  the  devices. 

•  To  determine  critical  timing  paths  in  designs. 

Tools 

•  None  commercially  available. 

Inputs 

•  Circuit  description. 

•  Operation  modes 

Outputs 

•  Timing  problems  in  the  circuit. 

•  Critical  paths. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  This  analysis  should  be  initiated  during  the  CD/V  phase  for  critical  items  and 
refined  during  the  FSD  detailed  design  phase 

Limitations,  Deficiencies,  Problems 

•  These  analyses  are  currently  manual  and  time  consuming. 

•  Complex  circuits  and  feedback  loops  are  difficult  to  analyze. 

•  Methods  using  worst  case  timing  for  all  devices  can  be  overly  pessimistic  and  fiiil  most  designs. 
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A4.0  PHYSICAL  DESIGN 


Physical  design  is  the  packaging  of  system-level,  LRU-level,  board-level,  and  component-level 
electronics.  The  following  sections  summarize  these  levels  of  physical  design. 

A4.1  SYSTEM  LEVEL  PHYSICAL  DESIGN 

Description 

System-level  physical  design  involves  the  packagingof  system  hardware,  envelope,  panels,  racks, 
and  other  hardware. 

Purpose 

•  To  physically  design  the  system  to  meet  spatial,  environmental,  functional,  reliability,  and 
maintainability  requirements. 

Tools 

•  MCAD  solid  modeling  tools:  Mentor  Package  Stations,  Intergraph,  CimLinc. 

Inputs 

•  System  size,  weight,  interface,  power  and  thermal,  nuclear  hardness,  survivability,  and 
environment  requirements. 

•  Parts  list. 

•  Trade  studies. 

Outputs 

•  2D  and  3D  drawings. 

•  System  physical  specifications. 

•  Interference  problems. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  System  level  physical  design  is  initiated  during  the  proposal  phase  and 

refined  in  subsequent  phases  of  the  design  process.  A  comprehensive  system- 
level  design  should  be  conducted  during  the  CE/D  phase. 

Associated  Military  Documents 

•  MIL-STD-454,  Standard  General  Requirements  for  Electronic  Equipment. 

Limitations,  Deficiencies,  Problems 

•  Few  physical  design  tools  are  integrated  witn  electronic  design  and  analysis  tools. . 

•  Available  tools  have  limited  representation  and  analysis  capabilities. 

•  Available  tools  do  not  effectively  address  data  management  and  documentation  needs. 
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A4.2  LRU/LRM  LEVEL  PHYSICAL  DESIGN 


Description 

Hardware  line  replaceable  units  (LRU)  or  modules  within  the  main  system  hardware  must  be 
physically  designed 

Purpose 

•  To  physically  design  modules  to  meet  spatial,  environmental,  functional,  reliability,  and 
maintainability  requirements  within  the  system  hardware. 

Tools 

•  MCAD  solid  modeling  tools:  Mentor  Package  Stations,  Intergraph,  CimLinc. 

Inputs 

•  System  hardware  design  specifications. 

•  LRU  size,  envelope,  weight,  interface,  power  and  thermal,  nuclear  hardness,  survivability,  and 
environmental  requirements. 

•  Trade  studies. 

Outputs 

•  2D  and  3D  drawings. 

•  Interference  problems. 

•  Board  specifications. 

Where  It  Fits  in  the  Design  Process 

Application  Phase:  LRU/LRM  level  physical  design  is  initiated  during  the  proposal  phase  and 
refined  in  subsequent  phases  of  the  design  process.  Although  a 
comprehensive  system-level  design  should  be  conducted  during  the  CE/D 
phase,  most  of  the  detailed  design  is  performed  in  the  FSD  phase. 

Associated  Military  Documents 

•  MIL-STD-1378,  Requirements  for  Employing  Standard  Electronic  Modules 

•  MIL-STD-1389,  Standard  Electronic  Modules,  Design  Requirements  for. 

Limitations,  Deficiencies,  Problems 

•  Few  physical  design  tools  are  integrated  with  electronic  design  and  analysis  tools.  . 

•  Available  tools  have  limited  representation  and  analysis  capabilities. 

•  Available  tools  do  not  effectively  address  data  management  and  documentation  needs. 
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A4.3  BOARD  LEVEL  PHYSICAL  DESIGN 


Board-level  design  involves  preliminary  layout,  layout,  routing,  and  generation  of  manufacturing 
data.  These  operations  are  summarized  in  the  following  sections. 

A4.3.1  Preliminary  Layout 

Description 

Preliminary  layout  of  components  on  the  board  identifies  initial  board  sizing  requirements, 
placement  problems,  testability,  and  other  information  that  can  help  prevent  downstream  problems. 
This  data  can  also  be  used  in  performing  preliminary  thermal  analysis  for  reliability. 

Purpose 

•  To  establish  a  preliminary  physical  layout. 

•  To  enable  spatial,  routability,  thermal,  electrical,  mechanical,  reliability,  testability, 
maintainability,  and  environmental  requirements  to  be  evaluated  early  in  the  design  process, 
when  changes  can  be  made  to  optimize  the  design. 

Tools 

•  ECAD  Printed  Wiring  Board  (PWB)  design  systems:  Mentor  Package  and  Board  Stations, 
Intergraph  system. 

Inputs 

•  Circuit  description. 

•  Parts  list. 

•  Board  description 

•  Layout  requirements. 

•  Electrical  requirements. 

•  Design  rules,  military  specification  requirements 

Outputs 

•  Preliminary  layout. 

•  Design  input  to  Package  Stations  thermal  capability. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Preliminary  layout  is  performed  during  the  CD/V  phase  to  estimate  board 
level  requirements  for  the  package  design.  It  is  also  performed  during  the 
detailed  design  phase,  when  complete  part  data  is  available  for  defining  the 
board  level  requirements  of  the  package  design. 
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A4.3.1  Preliminary  Layout  (concluded) 

Associated  Military  Documents 

•  MIL-STD-275E,  Printed  Wiring  for  Electronic  Equipment. 

•  MIL-P-55110,  Printed  Wiring  Boards 

•  MIL-P-28809,  Printed  Wiring  Assemblies. 

Limitations,  Deficiencies,  Problems 

•  There  are  currently  not  many  PWB  CAD  programs  that  can  take  electrical  requirements  into 
consideration  and  analyze  the  resulting  component  layout. 

•  There  are  no  direct  inputs  from  circuit  simulators  of  component  power  dissipation  data  to  thermal 
layout  tools. 

•  Optimization  tools  are  needed  that  will  optimize  component  placement,  board  interconnections, 
and  thermal  considerations  among  all  the  boards  within  the  LRU. 
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A4.3.2  Layout 
Description 

Layout  is  the  final  placement  optimization  of  components  on  boards  within  a  LRU. 

Purpose 

•  To  place  components  on  boards  to  meet  spatial,  routability,  thermal,  electrical,  mechanical, 
reliability,  testability,  maintainability,  and  environmental  requirements. 

Tools 

•  ECAD  PWB  design  systems.  Mentor  Package  and  Board  Stations,  Intergraph  system. 

Inputs 

•  Circuit  description 

•  Detail  parts  list. 

•  Board  description 

•  Layout  requirements 

•  Electrical  requirements. 

•  Design  rules,  military  specification  requirements. 

Outputs 

•  Component  layout  on  boards. 

•  Design  input  to  Package  Stations  thermal  capability. 

Where  It  Fits  in  the  Design  Process 

Phase  Aoplication:  Final  layout  is  performed  during  the  detailed  design  phase,  when  complete 
part  data  is  available  to  define  board-level  requirements  for  the  package 
design. 

Associated  Military  Documents 

•  MIL-STD-275E,  Printed  Wiring  for  Electronic  Equipment 

•  MIL-P-551 10,  Printed  Wiring  Boards. 

•  MIL-P-28809,  Printed  Wiring  Assemblies 

Limitations,  Deficiencies,  Problems 

•  There  are  currently  not  many  PWB  CAD  programs  that  can  take  electrical  requirements  into 
consideration  and  analyze  the  resulting  component  layout. 

•  There  are  no  direct  inputs  from  circuit  simulators  of  component  power  dissipation  data  to  thermal 
layout  tools. 

•  Optimization  tools  are  needed  that  will  optimize  component  placement,  board  interconnections, 
and  thermal  considerations  among  all  the  boards  within  the  LRU. 
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A4.3.3  Routing 
Description 

Component  connections  on  the  various  board  layers  must  be  optimally  routed. 

Purpose 

•  To  optimize  routes  to  meet  spatial  requirements  and  electrical  requirements  for  delay  times, 
capacitance,  inductance,  etc. 

Tools 

•  ECAD  PWB  design  systems:  Mentor  Board  Stations,  Intergraph  system. 

Inputs 

•  Circuit  description. 

•  Parts  list. 

•  Board  description. 

•  Component  layout  of  boards. 

•  Electrical  requirements 

•  Design  rules,  military  specification  requirements. 

Outputs 

•  Routed  board 

•  Design  input  to  manufacturing  interface. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Routing  is  part  of  the  detailed  design  process  and  occurs  after  the  electronics 
design  has  been  finalized. 

Associated  Military  Documents 

•  M1L-STD-275E,  Printed  Wiring  for  Electronic  Equipment. 

•  MlL-P-551 10,  Printed  Wiring  Boards 

•  .vllL-P-28809,  Printed  Wiring  Assemblies. 
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A4.3.3  Routing  (concluded) 

Limitations,  Deficiencies,  Problems 

•  Current  PWB  CADprograms  are  generally  not  capable  of  taking  electrical  requirements  into 
consideration,  analyzing  the  resulting  routing  of  component  connections,  or  providing  electrical 
data  (such  as  delay  times,  capacitance,  inductance,  etc.)  to  circuit  simulators. 

•  Because  of  tight  schedules  that  do  not  allow  sufficient  time  for  layout  optimization,  routing  is 
sometimes  started  before  the  layout  optimization  is  complete. 

•  Design  rules  in  automatic  routing  programs  do  not  take  into  consideration  electrical  requirements, 
such  as  delay  times,  capacitance,  inductance,  etc. 

•  The  routability  analyses  performed  by  most  automatic  routing  programs  are  often  not  capable  of 
correctly  determining  whether  a  proposed  layout  can  be  routed  successfully.  As  a  result, 
engineering  manhours  and  resources  are  often  wasted  in  an  attempt  to  route  layouts  that  are  not 
routable.  The  expense  of  routing  boards  in  which  the  electrical,  thermal,  and  routability  and 
spatial  requirements  are  optimized  can  become  prohibitive. 
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A4.3.4  Manufacturing  Data  Generation 
Description 

The  PWB  design  data  must  be  prepared  for  manufacturing.  This  includes  generating  layer  artwork, 
numerical  control  drill  and  trim  data,  fabrication  drawings,  military  specification  test  coupons, 
fabrication-unique  patterns  (e  g  ,  epoxy  flow  scallop  patterns),  and  manufacturing  board  blank  layout 
(optimization  of  PWB  patterns  per  manufacturing  board  blank). 

Purpose 

•  To  link  CAD  processes  with  CAM  processes  and  hardware. 

Tools 

•  EC  AD  PWB  design  systems:  Mentor  Board  Stations,  Intergraph  system. 

Inputs 

•  Board  routes. 

•  Component  placement 

•  Board  definition. 

•  Board  layer  stack  up 

Outputs 

•  Layer  artwork 

•  Numeric  control  drill  and  milling  data. 

•  Fabrication  and  assembly  drawings 

•  Military  specification  test  coupons 

•  Fabrication-unique  patterns. 

•  Manufacturing  board  blank  layout 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Generation  of  manufacturing  data  occurs  in  the  production  phase,  however, 
PWBs  may  be  manufactured  as  prototypes  in  the  FSl)  phase. 

Associated  Military  Documents 

•  MIL  STD-275K,  Printed  Wiring  for  Electronic  Equipment. 

•  M1L-P-551 10,  Printed  Wiring  Boards. 

•  MIL  P  28809,  Printed  Wiring  Assemblies. 

Limitations,  Deficiencies,  Problems 

•  Design  revisions  are  costly  once  manufacturing  data  has  been  generated 
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A4.4  COMPONENT  LEVEL  PHYSICAL  DESIGN 


Description 

Physical  design  at  the  component  level  includes  the  design  of  custom  integrated  circuits,  gate  arrays, 
and  hybrids. 

Purpose 

•  To  design  functions  to  fit  limited  space  requirements. 

Tools 

•  IC  design  systems  and  tools:  Chipgraph  Stations. 

Inputs 

•  Circuit  and  package  description. 

•  Electrical  requirements. 

•  Trade  studies. 

Outputs 

•  Semiconductor  fabrication  description  language  specific  to  vendor  fabrication  house 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Semiconductor  component  design  requires  long  lead  times  and  therefore  must 
be  started  early  in  the  detailed  design  phase,  if  not  in  the  conceptual  phase  A 
commitment  must  be  made  early  to  bu  ild  a  custom  IC,  and  thus  to  design 
supporting  circuitry  around  the  custom  IC. 

Limitations,  Deficiencies,  Problems 

•  Determining  the  testability  of  custom  ICs,  gate  arrays,  and  hybrids  is  difficult 

•  IC  design  must  be  frozen  early;  changes  are  expensive  and  require  long  lead  times. 

•  Requires  computer-intensive  capability  to  fully  simulate  design. 

•  IC  development  libraries  are  frequently  vendor  and/or  fabrication  specific  Changing  vendors 
and/or  process  technology  may  require  redesign  to  the  specific  new  vendor  or  technology  process. 
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A4.5 THERMAL  ANALYSIS 


Description 

Thermal  analysis  is  used  to  predict  component  temperatures  and  thermal  stress  under  a  variety  of 
operating  conditions.  Device  power  dissipation,  cooling,  placement,  and  other  information  are  used  to 
calculate  this  information. 

Purpose 

•  To  determine  the  need  for  and  the  effectiveness  of  a  design's  environment  control  provisions. 

Tools 

•  Therml  analysis  tools:  AUTOTHERM,  THERMAL. 

Inputs 

•  Item  description  at  the  circuit  board  level  (e.g.,  arrangement  of  circuit  boards,  external  heat 
sources) 

•  Power  dissipation  of  each  device  or  group  of  devices. 

•  Board  and  package  design  (e.g.,  layout,  materials). 

•  Environmental  control  provisions  (e.g.,  cooling  capacity,  location,  temperature). 

Outputs 

•  Temperature  of  each  component. 

•  Problem  areas. 

•  Thermal  gradients 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Thermal  analyses  should  begin  once  the  packaging  of  the  circuit  is  available. 

Analyses  may  begin  early  in  the  design  using  simplified  models  to  assist  in 
identifying  potential  problem  areas.  Estimates  of  the  board  layout  and 
packaging,  component  power  dissipations,  and  cooling  effectiveness  are 
required  to  perform  the  analyses. 
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A 5.0  RELIABILITY  AND  MAINTAINABILITY 


A5.1  RELIABILITY 

A5.1.1  Failure  Modes  and  Effects  Analysis 
Description 

Failure  modes  and  effects  analysis  (FMEA)  is  used  to  determine  the  effects  that  failures  in  a  system 
have  on  the  operation  of  the  system.  This  determination  can  be  used  to  produce  maintenance 
procedures,  calculate  mission  success  probabilities,  etc.  The  analysis  can  be  done  at  all  levels  of 
design,  from  system  level  to  individual  components. 

Purpose 

•  To  identify  the  effects  of  item  failures  on  system  operation. 

•  To  ensure  no  single  failure  poses  a  safety  problem  or  will  result  in  the  loss  of  equipment. 

•  To  classify  failure  effects  according  to  their  severity. 

Tools 

•  None  commercially  available. 

Inputs 

•  System  definition  (e  g  ,  functional  block  and  flow  diagrams,  circuit  diagrams). 

•  Failure  modes  and  rates 

•  Mission  function  and  operational  modes 

•  Operational  information  (e  g  ,  duty  cycle,  environmental  conditions). 

•  Reliability  block  diagrams 

Outputs 

•  FMEA  worksheets 

•  Failure  effects 

•  Failure  detection  method 

•  Compensating  provisions 

•  Severity  classification 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  FMEA  should  be  initiated  during  Systems  Engineering,  using  system  level 
models,  and  refined  during  Detailed  Design.  An  in-depth  analysis  should  be 
conducted  during  the  CD/V  phase 

Limitations,  Deficiencies,  Problems 

•  Currently  a  manual,  time  consuming  process. 
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A5.1.2  Failure  Modes  and  Effects  Criticality  Analysis 
Description 

Failure  modes  and  effects  criticality  analysis  (FMECA)  is  used  to  rank  each  potential  failure  mode 
identified  during  FME  A  according  to  its  severity  and  probability  of  occurrence. 

Purpose 

•  To  identify  and  rank  the  most  critical  failures. 

Tools 

•  None  commercially  available. 

Inputs 

•  Failure  effects. 

•  Failure  severity. 

•  Failure  rates  and  probability. 

•  Operating  time. 

Outputs 

•  Criticality  analysis  worksheet. 

•  Item  criticality. 

•  Criticality  matrix. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  FMECA  should  be  initiated  during  Systems  Engineering,  using  system-level 
models,  and  refined  during  Detailed  Design.  An  in-depth  analysis  should  be 
conducted  once  detailed  circuit  schematics  become  available. 

Limitations,  Deficiencies,  Problems 

•  FMECA  is  currently  a  manual,  time  consuming  process. 
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A5. 1.3  Fault  Tree  Analysis 
Description 

Fault  tree  analysis  (FTA)  is  used  to  determine  the  probability  of  failure  of  events  in  a  fault  tree. 
Purpose 

•  To  determine  the  probabilities  of  failure  of  the  events  in  a  fault  tree. 

Tools 

•  Fault  tree  programs:  FTREE,  SETS,  SEP. 

Inputs 

•  Failure  rates  and  exposure  time. 

•  Fault  tree  logic. 

Outputs 

•  Failure  probabilities  of  fault  tree  events. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  A  fault  tree  analysis  can  be  performed  at  any  point  in  the  design. 
Limitations,  Deficiencies,  Problems 

•  Due  to  their  size  and  complexity,  current  designs  cannot  be  modeled  within  existing  fault  tree 
programs  unless  simplifying  assumptions  are  made  or  only  part  of  the  design  is  modeled. 

•  Existing  tools  do  not  provide  the  needed  data  management  and  documentation  capabilities. 
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A5.1.4  Mission  Analysis 
Description 

Mission  success  probability  is  the  probability  that  the  system  can  complete  a  specified  mission.  The 
prediction  is  a  function  of  the  inherent  reliability  of  the  design  (basic  failure  rates),  the  fault 
tolerance  of  the  design,  the  mission  profile,  and  other  factors. 

Operational  availability  is  defined  as  the  ratio  of  time  that  the  system  is  operating  to  the  time 
required  to  maintain  the  system  in  an  operational  state.  The  formula  is  - 

uptime  /  (uptime  +  downtime  +  repair  time  +  response  time) 

This  differs  from  inherent  availability,  which  does  not  include  downtime  or  response  time  in  the 
calculation. 

Purpose 

•  To  determine  the  probability  of  mission  completion. 

•  To  predict  the  availability  of  the  system  in  order  to  better  estimate  the  number  of  system  unit 
needed  to  complete  the  mission. 

Tools 

•  Mission  modeling  programs:  MIREM,  C  ARM  A,  CEPFRA. 

Inputs 

•  FMECA  inputs. 

•  MTTR. 

•  Response  times. 

•  System  mission  profiles. 

Outputs 

•  Mission  success  probability. 

•  Operational  availability. 

•  Major  contributors  to  system  unreliability. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Mission  analyses  should  be  estimated  as  part  of  the  initial  proposal  and 
refined  during  subsequent  phases  as  part  of  the  system  architecture 
>  definition.  The  results  of  the  analysis  should  be  updated  as  more  detailed 

system  and  Cl  design  information  become  available.  A  comprehensive 
'  analysis  should  be  completed  prior  to  finalizing  the  segment  and  Cl 

specifications. 

Limitations,  Deficiencies,  Problems 

•  Available  tools  not  sufficiently  robust  for  large  scale  programs. 

k  •  Available  tools  not  integrated  with  electronic  design  systems. 

,  •  Available  tools  do  not  provide  adequate  data  management  and  documentation  capabilities. 
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A5. 1.5  Reliability  Analysis 
Description 

Reliability  is  the  probability  that  a  system,  module,  or  component  will  operate  without  failure  for 
specified  period  of  time.  Device  reliability  is  calculated  from  temperature,  loading,  stress,  usage 
(activity)  of  device,  and  other  factors.  The  reliability  of  the  circuit  is  calculated  from  the  reliability  of 
each  component  in  the  circuit,  the  usage  of  each  device,  the  fault  tolerance  of  the  circuit,  and  other 
considerations. 

Reliability  predictions  are  used  in  analyses  to  validate  concepts,  verify  designs,  estimate  number  of 
spares,  produce  maintenance  schedules,  etc.  The  failure  rate  and  MTBF  are  used  in  the  calculation  of 
spares,  maintenance  timelines,  FMECA,  mission  success  probabilities,  and  MTTR  (among  other 
parameters).  MTBDE  is  used  to  determine  the  frequency  of  failures  that  cause  the  system  to  become 
nonfunctional  and  to  calculate  number  of  spares  required,  maintenance  timelines,  FMECA,  mission 
success  probability,  MTTR,  etc. 

Purpose 

•  To  predict  the  reliability  of  an  electronic  system  and  various  mean  time  between  any  failure 
parameters. 

Tools 

•  Reliability  modeling  and  prediction  programs:  STROP,  CARMA,  CEPFRA,  REAP. 

Inputs 

•  Circuit  description 

•  Device  operating  data:  electrical  stress,  temperature,  power  dissipation,  etc. 

•  F  unctional  description  of  circuit  including  a  detailed  definition  of  fault-tolerant  design. 

Outputs 

•  MTTF  and  MTBF  of  each  part. 

•  MTBF  and  MTBCF  of  circuit  board  or  system 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  The  reliability  of  a  system  should  be  estimated  as  part  of  the  initial  proposal 
and  refined  during  the  CE/D  phase  to  establish  the  system  architecture.  The 
results  of  the  analysis  should  be  refined  in  subsequent  phases  of  the  design  as 
more  detailed  system  and  Cl  design  information  become  available.  A 
comprehensive  analysis  should  be  completed  prior  to  finalizing  the  segment 
and  Cl  specifications. 

Limitations,  Deficiencies,  Problems 

•  Predictions  may  not  equate  to  real  world  failures. 

•  Available  tools  not  sufficiently  robust  for  large  scale  programs. 

•  Available  tools  not  integrated  with  electronic  design  systems. 

•  Available  tools  do  not  provide  adequate  data  management  and  documentation  capabilities. 
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AS.  1.6  Thermal  Analysis 


Description 

Thermal  analysis  is  used  to  predict  component  temperatures  under  a  variety  of  operating  conditions 
for  a  detailed  reliability  analysis.  Device  power  dissipation,  cooling,  placement,  and  other 
information  are  used  to  calculate  the  temperature. 

Purpose 

•  To  determine  the  temperature  of  each  device  in  the  circuit  in  order  to  predict  component  failure 
rates. 

Tools 

•  Thermal  analysis  programs:  AUTOTHERM,  THERMAL. 

Inputs 

•  Item  description  at  the  circuit  board  level  (e.g.,  arrangement  of  circuit  boards,  external  heat 
sources) 

•  Power  dissipation  of  each  device. 

•  Board  and  package  design  (e  g.,  layout,  materials). 

•  Environmental  control  provisions  (e.g.,  cooling  capacity,  location,  temperature). 

Outputs 

•  Temperature  of  each  component. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Thermal  analysis  for  reliability  analysis  is  usually  performed  during  the 
detailed  design  phase  by  dedicated  thermal  analysts  Board  layout, 
packaging  description,  component  power  dissipation,  and  cooling  information 
are  required  to  perform  the  analysis. 

Limitations,  Deficiencies,  Problems 

•  Available  tools  not  sufficiently  robust  for  large  scale  programs. 

•  Existing  tools  do  not  provide  the  needed  data  management  and  documentation  capabilities. 


A5.2  MAINTAINABILITY 


The  following  sections  describe  tasks  1  elating  to  the  maintenance  of  a  system.  The  results  are  used  to 
develop  procedures  for  maintaining  the  system. 

A5.2.I  Maintainability  Allocations  and  Analyses 

Description 

Maintainability  timeline  analyses  are  needed  to  establish  the  maintenance  schedules  for  various 
elements  of  a  system.  MTTR,  Mmax,  and  analyses  yield  predictions  of  the  mean  and  maximum  repair 
times  needed  to  restore  the  system  to  operation.  These  analyses  are  based  on  failure  rates,  element 
weights,  redundancy  and  fault-tolerance,  maintainability  calculations,  failure  moues,  and  fault 
detection  capabilities  of  the  system. 

Purpose 

•  To  determine  the  mean  and  maximum  times  needed  to  repair  the  system. 

•  To  establish  maintenance  schedules  for  the  system. 

Tools 

•  Maintainability  prediction  programs:  AMAP,  MEAP. 

Inputs 

•  System  description. 

•  FD/F1. 

•  FMA 

•  Failure  rate  data. 

Outputs 

•  Maintainability  parameters:  MTTR,  MTBMA,  Mmax,  etc. 

•  Maintenance  schedules. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  The  maintainability  parameters  should  be  estimated  as  part  of  the  initial 

proposal  and  refined  during  the  CE/D  phase  to  establish  the  maintenance  and 
support  concepts.  The  results  of  the  analyses  should  be  refined  in  subsequent 
phases  of  the  design  as  more  detailed  system  and  Cl  design  information 
become  available.  A  comprehensive  analysis  should  be  completed  prior  to 
finalizing  the  segment  and  Cl  specifications. 

Limitations,  Deficiencies,  Problems 

•  Available  tools  not  integrated  with  electronic  design  systems. 

•  Available  tools  do  not  provide  adequate  data  management  and  documentation  capabilities. 
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A5.2.2  Failure  Reporting,  Analysis,  and  Corrective  Action  System 
Description 

The  Failure  Reporting,  Analysis,  and  Corrective  Action  System  (FRACAS)  is  used  for  tracking 
failures  of  equipment.  It  consists  of  the  following  functions: 

•  Collection  of  removal  and  failure  data  in  end  items. 

•  Identification  of  failed  assemblies,  subassemblies,  and  parts. 

•  Identification  of  the  exact  part  cause  of  failure. 

•  Physics  of  failure  analysis,  if  necessary. 

•  Corrective  action  and  followup. 

•  Trend  analysis  to  identify  problems. 

Purpose 

•  To  collect,  catalog,  and  report  failures  of  equipment  to  the  customer,  user,  and  contractor 
Tools 

•  None  commercially  available. 

Inputs 

•  Field  reliability  and  maintainability  data. 

•  Operator  comments. 

Outputs 

•  Reliability  and  maintainability  problem  areas. 

•  Actions  (e  g.,  redesign,  manufacturing  process  changes)  needed  to  address  problem  areas. 

•  Correlations  of  field  reliability  and  maintainability  data. 

Where  It  Fits  in  the  Design  Process 

Application  Phase:  Performed  as  part  of  extensive  field  tests  or  after  the  system  has  been 
deployed. 


192 


A6.0  LOGISTICS  -  MAINTENANCE  PREDICTIONS 


The  following  tasks  are  performed  to  schedule  maintenance  and  estimate  the  spares  required  to  meet 
system  availability  requirements. 

A6.1  REPAIR  TIME  ANALYSIS 

Description 

Repair  time  analysis  evaluates  the  design  to  determine  the  time  needed  to  repair  various  parts  of  the 
system.  The  analysis  is  generally  performed  by  a  the  Logistics  Support  Analysis  group. 

Purpose 

•  To  determine  the  time  to  repair  the  system. 

•  To  predict  availability  and  maintenance  schedules. 

Tools 

•  AMAP 
Inputs 

•  System  description. 

•  FD/FI. 

•  FMA. 

Outputs 

•  Repair  times. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  The  analysis  should  be  performed  as  part  of  the  initial  proposal  and  the 

results  refined  during  subsequent  phases  as  details  for  individual  LRUs  and 
LRM  become  available.  A  comprehensive  analysis  should  be  completed  prior 
to  finalizing  the  segment  and  Cl  specifications. 

Limitations,  Deficiencies,  Problems 

•  Analysis  results  are  often  not  updated  as  the  design  progresses  and  accurate  estimates  of  repair 
time  are  often  not  available  until  after  the  design  is  finalized. 

•  Available  tools  not  integrated  with  electronic  design  systems. 

•  Available  tools  do  not  provide  adequate  data  management  and  documentation  capabilities. 
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A6.2  MAINTENANCE 


Description 

Maintenance  evaluates  the  design  to  determine  maintenance  scheduling  to  meet  availability 
requirements.  Data  from  FMA,  FMECA,  repair  times,  and  failure  rates  are  used  to  determine  the 
optimum  schedule.  The  analysis  is  generally  performed  by  the  Logistics  Support  Analysis  group. 

Purpose 

•  To  determine  maintenance  schedules  to  achieve  required  level  of  system  availability. 

Tools 

•  None  commercially  available. 

Inputs 

•  System  description. 

•  Repair  times. 

•  Failure  rates. 

•  FD/FI 

•  FMA. 

•  FMECA 

Outputs 

•  Maintenance  schedules. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  The  analysis  should  be  performed  as  part  of  the  initial  proposal  and  the 

results  refined  during  subsequent  phases  as  details  for  individual  LRUs  and 
LRM  become  available.  A  comprehensive  analysis  should  be  completed  prior 
to  finalizing  the  segment  and  Cl  specifications. 

Limitations,  Deficiencies,  Problems 

•  Analysis  results  are  often  not  updated  as  the  design  progresses  and  accurate  maintenance 
schedules  are  often  not  available  until  after  the  design  is  finalized. 

•  Available  tools  not  integrated  with  electronic  design  systems. 

•  Available  tools  do  not  provide  adequate  data  management  and  documentation  capabilities. 
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A6.3  SPARES  ANALYSIS 


Description 

A  spares  analysis  evaluates  the  description  of  the  system,  repair  times,  failure  rates,  and  basing  to 
determine  spares  requirements.  The  analysis  is  generally  performed  by  the  Logistics  Support 
Analysis  group. 

Purpose 

•  To  determine  the  number  and  location  of  spares  needed  to  achieve  specified  system  availability. 

Inputs 

•  System  description. 

•  Repair  times. 

•  Failure  rates. 

•  Basing  data 

Outputs 

•  Spares  data. 

Where  It  Fits  in  the  Design  Process 

Phase  Application:  Spares  requirements  should  be  estimated  as  part  of  the  initial  proposal  and 
refined  during  subsequent  phases  as  details  for  individual  LRUs  and  LRMs 
become  available.  A  comprehensive  analysis  should  be  completed  prior  to 
finalizing  the  segment  and  Cl  specifications 

Limitations,  Deficiencies,  Problems 

•  The  spares  analysis  is  often  not  updated  as  the  design  progresses  and  the  requirements  are  often 
not  determined  until  after  the  design  is  finalized. 

•  Available  tools  not  integrated  with  electronic  design  systems. 

•  Available  tools  do  not  provide  adequate  data  management  and  documentation  capabilities 
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APPENDIX  B:  DESIGN  PROCESS  TOOLS 


BL.O  OVERVIEW 

This  appendix  is  a  sampling  of  the  tools  commonly  used  in  the  design  of  electronics.  The  tools  listed 
are  some  of  the  more  popular  and  widely  used,  although  there  are  many  more  tools  available, 
including  spreadsheets  and  database  management  systems. 

A  select  subset  of  tools  with  a  listing  of  their  important  characteristics  is  shown  in  table  B-l 

Detailed  descriptions  of  the  tools  follow  table  B-l.  Each  description  contains  several  sections 
describing  the  important  characteristics  of  the  tool,  as  follows: 

*  Description:  Describes  the  tool 

•  Purpose:  Explains  why  and  when  the  tool  may  be  used. 

•  Analyses  Supported:  Lists  the  types  of  analyses  that  the  tool  supports  and  an  estimated 
percentage  of  the  task  that  the  tool  performs. 

#  Inputs:  Lists  the  major  data  needed  by  the  tool. 

♦  Outputs:  Lists  the  major  data  that  the  tool  produces. 

•  Other  Data:  Lists  other  related  data  about  the  tool. 

*  Limitations,  Deficiencies,  Problems:  Where  applicable,  lists  any  known  information  in  these 
areas 

Where  there  is  no  information  under  a  particular  heading,  the  heading  is  omitted. 
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TABLE  B-1 .  Analyses  Tool  Matrix 


Too) 

Function 

Analyses  supported 

Inputs 

Outputs 

RDD100 

1 

•  Functional  analysis 

•  Functional  flow 
analysis 

•  Functional 
allocation 

•  Performance 
requirements 
analysis  and 
allocation 

•  Functional 
description  of 
system 

•  Requirements 

•  Data,  information, 
and  control  flows 

•  Functional 
diagrams 

CASA 

•  Life  cycle  cost 

•  LCC  analysis 

•  Spares  analysis 

•  Operational 
availability 
analysis 

•  Risk  and 
uncertainty 
analysis 

•  System  description 

•  LCC  data 

•  Risk  data 

•  LCC  predicitons 

•  Cost  drivers 

•  Sensitivity  analyses 

•  Risk  analysis 

MIREM 

•  Mission  and  system 
reliability  analysis 

•  Mission  and  system 
reliability 

•  Operational 
availability 

•  System  functional 
description 

•  Mission  scenario 

•  Reliability  and 
maintainability 
data 

•  System  reliability 
and  availability 

•  MCSP 

•  MTBCF 

•  Failure  resiliency 

•  MTBMA 

AWARE 

•  Failure  rate 
predictor 

•  Mean  time 
between  failures 
(MTBF) 

•  Mean  time 
between  downing 
events  (MTBDE) 

•  Electronic  parts 
characteristics 

•  Temperature  of 
components 

•  Electrical  stress  of 
components 

•  MTBF  of  parts 

•  MTBF  of 
assemblies 

CARMA 

•  Reliability 
predictor 

•  Mission  reliability 

•  Installation  data 

•  Mission  phase 
profile 

•  Assembly  duty 
profile 

•  System 
configuration 

•  Assembly  failure 
rates 

•  System  reliability 

•  Reports 

•  Reliability  block 
diagrams 

CEPFRA 

•  Reliability  and 
availability 
predictor 

•  Reliability 

•  Operational 
availability 

•  Failure  and/or 
repair  rates 

•  initial  conditions  of 
system  in  terms  of 
reliability 

•  Mission  time  for 
reliability  and 
point  and  interval 
availability 

•  Absorbing  process 

-  reliability  /  MTBF 

•  Ergodic  process 
availability 

•  Absorbing  process 

-  availability 
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TABLE  B-1.  Analyses  aTool  Matrix  (Continued) 


Tool 

Function 

Analyses  supported 

Inputs 

Outputs 

REAP 

•  Reliability 
predictor 

•  Reliability 

•  Failure  rates 

•  MIL-HDBK-217 
data 

•  Part  numbers  and 
reference 
designators 

•  System 
configuration 
(drawing  tree) 

•  Assembly  failure 
rate  breakdown 

•  System 

configuration  tree 

•  Failure  rate  versus 
temperature  plot 

ReCaic  2 

SysCaic 

•  System  reliability 
predictor 

•  System  failure  rate 

•  System  MTBF 

•  System 

configuration  data 

•  Parts 

characteristics 

•  “a^ts  applications 

•  System  failure  rate 

•  System  MTBF 

AM 

•  Repar  time 
est  mator 

•  Mean  bme  to 
reoair(MTTR) 

•  Mmax 

•  Description  of 
system 

•  Location  of 
maintenance 

action 

•  Quantity  of 
identical  SRUs  used 
m  the  assembly  or 

unit 

•  Failure  rate  for 

SRU 

•  Corrective 
maintenance  data 

•  MTTR 

•  Mmax 

•  Corrective 
maintenance 
timeline 

ME  AP 

•  Maintainability 
ana'ysis 

•  MTTR 

•  Mean  down  time 

•  Max  corrective 
maintenance  t.me 

•  System  description 

•  MILHD8K-472 
data 

•  MTTR 

•  Mean  down  time 

•  Max  corrective 
maintenance  time 

Ou'Ct  Fault 

•  Fault  Simulator 

•  Fault  detection 
and  fault  isolation 

•  Ejilure  modes 
analysis  (FMA) 

•  Failure  modes 
effects  analysis 
(FMEA). 

•  Failure  modes 
criticality  analysis 
(FMECA) 

•  Fault  tree  analysis 
(ETA) 

•  Testability 

•  C.rcuit  description 

•  Test  vectors 
(stimulus) 

•  Fault  list 

•  Models 

•  Fault  dictionary 

•  Detected  and 
undetected  faults 

•  Detection  statistics 

Qu'CkSim 

•  Logic  simulator 

•  Digital  functional 
verification 

•  Nominal  timing 
verification 

•  Circuit  schematic 
(captured  with 
NETED) 

•  Test  vector 
(stimulus) 

•  Models 

•  Signal  list 

•  Signal  traces 
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TABLE  8-1.  Analyses  Tool  Matrix  (Concluded) 


Tool 

Function 

Analyses  supported 

Inputs 

Outputs 

SABER 

i 

i 

•  Analog  systems 
simulator 

•  System-level  and 
analog  functional 
analysis 

•  Worst  case  analysis 

•  System  description 

•  Test  stimulus 

•  Models 

•  System  outputs 

•  Sensitivity  analysis 
result 

•  Fourier  results 

MSPICE 

•  Analog  simulator 

•  Analog  functional 
analysis 

•  Worst  case 
analysis 

•  loading  analysis. 

•  Power  dissioaton 

•  Analog  Circuit 
description 

•  Test  stimulus 

•  Models 

•  Data  array 
containing 
voltages  at  all 
nodes  for  each 
analysis  point 

•  Charts  created 
from  node  data 

T> 

•  Topological 
testability  checker 

•  Testability 

•  Circuit  desc  ipt-on 

•  Testability  rules 
not  followed 

Package  Station 
(with 

AutoTherm) 

•  3-D  packaging 
aesign  including 
thermal  analysis 

•  3-D  packaging 
design 

•  Thermal  analys-s 

•  Physical  board 
design 

•  Package 

descr  utions  and 
spec  t'cations 

• .  pmponent  cata 

•  Cooing 
specifications 

•  Package  drawings  | 

•  Board  isctber^a' 
maps 

•  Component 
rerr>peraru  es 

Board  Station 
(with  layout  and 
Autorouter) 

•  Board  layout 

•  Printed  wirmg 
board  routing 

•  Physical  ooa-rl 
layout 

•  Routmg 

•  Component 
connection  list 

•  Parts  1st 

•  Physciai 

component  mode's 

•  Board  description 
and  specification 

•  PhyS'lj  hoard 
ayou*  a"d  rOuting 

•  Layer  d-.vork 

•  Assembly  and 
fabrication 
drawings 

•  Drill  oa'a 

•  Layout  da*a  for 
Package  Station 
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B2.0  SYSTEM  DESIGN 


B2.1  RDD100 
Description 

RDD100  (Requirements  Driven  Design)  assists  in  capturing  and  analyzing  requirements,  function 
descriptions,  and  function  dependencies. 

Purpose 

•  To  capture  and  manage  the  information  associated  with  functional  analysis  and  allocation. 

Analyses  Supported 

•  Functional  analysis  -  60%. 

•  Functional  allocation -60%. 

•  Performance  requirements  analysis  and  allocation  -  40%. 

Inputs 

•  Requirements. 

•  System  functional  description. 

•  Data,  information,  and  control  flows. 

Outputs 

•  Functional  diagrams. 

Other  Data 

•  Commercial  product  (Ascent  Logic). 
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B2.2  COST  EFFECTIVENESS  ANALYSIS  PROGRAM 


Description 

The  Cost  Effectiveness  Analysis  Program  (CHEAP)  performs  system  cost  predictions  based  on 
development,  acquisition,  operation,  and  support  data. 

Purpose 

•  To  assess  the  cost  of  design  alternatives,  allowing  prediction  of  life  cycle  costs  from  model'-' 
developed  with  the  system. 

•  To  perform  iterative  calculations  based  on  changes  in  reliability,  maintainability,  spares, 
inventory  management,  etc 

•  To  perform  most  of  the  work  required  for  LCC  analysis. 

•  To  support  trade  studies  and  concept  development  by  giving  life  cycle  costs  when  required 

Analyses  Supported 

•  LCC  optimization  -  80% 

•  Trade  studies  -  30% 

•  Concept  development  -  5%. 

Inputs 

•  System  description 

•  LCC  data 

•  System  data  on  reliability,  maintainability,  etc 

Outputs 

•  LCC  predictions. 

Other  Data 

•  Commercial  product 
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B2.3  CASA 


Description 

The  Cost  Analysis  Strategy  Assessment  (CASA)  program  provides  support  for  life  cycle  cost  analyses. 
Life  cycle  costs  are  computed  based  upon  research  and  development,  production,  and  operations  and 
support  element  costs.  Cost  can  be  displayed  in  a  hierarchy,  with  costs  rolled  up  to  any  level  of  detail. 
CASA  contains  the  following  analysis  programs: 

•  LCC  -  Life  cycle  cost  predictions. 

•  SENSE  -  LCC  sensitivity  analysis 

•  RISKMC  and  RISKOUT  -  Monte  Carlo  simulation  of  LCC. 

Purpose 

•  To  support  life  cycle  cost  analysis  for  complex  systems  with  repair. 

Analyses  Supported 

•  LCC  analysis. 

Inputs 

•  System  description 

•  LCC  data. 

•  Risk  data 

Outputs 

•  LCC  predictions. 

•  Cost  drivers. 

•  Sensitivity  analyses 

•  Risk  analysis 

Other  Data 

•  Do I)  product. 

Limitations,  Deficiencies,  Problems 

•  Availability  of  program  currently  limited. 

•  Limited  number  of  LRUs  and  subsystems  can  be  modeled. 

•  Not  integrated  with  existing  electronic  design  systems. 

•  Limited  data  management  and  documentation  capabilities. 
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B2.4  PROGRAMMED  REVIEW  OF  INFORMATION  FOR  COSTING  AND  EVALUATION 


Description 

The  Programmed  Review  of  Information  for  Costing  and  Evaluation  (PRICE)  is  a  family  of  RCA  cost 
prediction  models: 

•  PRICE  H  -  Estimates  hardware  development  and/or  production  costs. 

•  PRICE  H  L  -  Estimates  the  cost  of  operating  and  maintaining  the  more  complex  hardware  items 
and  systems. 

•  PRICE  M  -  Similar  to  PRICE  H,  but  estimates  hardware  development  and/or  production  costs  for 
systems  composed  of  small  items  such  as  microelectronics. 

•  PRICE  S  -  Also  similar  to  PRICE  H,  but  estimates  development  and/or  production  costs  for 
software. 

•  PRICE  SL  -  Estimates  software  maintenance  and  support  costs. 

•  PRICE  Auxiliary  Programs  -  Supports  selection  of  inputs  to  or  processing  outputs  of  PRICE 
models. 

Purpose 

•  To  derive  individual  or  life  cycle  hardware  and  software  cost  estimates. 

Analyses  Supported 

•  LCC  optimizations  -  90% 

Inputs 

•  PRICE 

-  Electronics  weight 

-  Mechanical  and  structural  weight. 

-  Densities 

-  Volume. 

-  Quantities. 

-  Amount  of  design  repetition. 

•  PRICE  II 

-  Unit  MTBF 

-  Repair  times. 

-  Hardware  costs. 

-  Quantities  and  learning  curves. 

-  Test  equipment  costs. 

-  Number  of  modules  and  parts  per  unit. 

-  Number  of  maintenance  locations. 

-  Transportation. 

-  Stockage 
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B2.4  PROGRAMMED  REVIEW  OF  INFORMATION  FOR  COSTING  AND  EVALUATION 
(concluded) 

-  Labor  rates. 

-  Scrap  and  maintenance  concepts. 

Outputs 

•  PRICE. 

-  Engineering  and  manufacturing  costs. 

-  Development  and/or  production  costs. 

-  Economic  basis  of  costs. 

-  U  ncertainty  of  cost  measurements. 

•  PRICE  H. 

-  Life  cycle  cost  (LCC). 

-  Availability  and  readiness  location. 

-  N umber  of  test  equipment  sets. 

-  Total  costs. 

Othe»-  Data 

•  Commercial  product. 

Limitations,  Deficiencies,  Problems 

•  Proprietary  programs  and  algorithms  are  not  available  to  users. 

•  PRICE  can  be  used  only  by  subscription  with  RCA. 
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\  B3.0  DETAILED  DESIGN 


B3.I  LOADING  _ANALYSIS 
Description 

Loading _ Analysis  is  a  DC  loading  analysis  tool  developed  by  Boeing. 

Purpose 

•  To  provide  DC  loadings  of  the  pins  of  electronic  components. 

Analyses  Supported 

•  DC  loading  analysis -75%. 

Inputs 

•  Circuit  net  list. 

•  Parts  list. 

•  Component  data. 

Outputs 

•  DC  loading  of  each  pin  of  the  electronic  components. 

Other  Data 

•  Boeing  product. 

Limitations,  Deficiencies,  Problems 

•  Only  DC  loading  is  provided 

•  No  AC  effects  are  provided. 


i 
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B3.2  MSPICE 


Description 

MSPICE  is  Mentor’s  graphical  interface  to  the  SPICE  analog  simulation  tool.  It  is  a  general-purpose, 
nonlinear  analog  circuit  simulation  tool  that  performs  several  types  of  analyses. 

Purpose 

•  To  perform  four  types  of  analyses:  DC  operating  point,  DC  sweep,  AC  sweep,  and  transient. 

Analyses  Supported 

•  Analog  functional  analysis  -  50%. 

•  Worst  case  analysis  -  25%. 

•  Loading  analysis -25%. 

•  Power  dissipation  -  50%. 

Inputs 

•  Analog  circuit  (captured  with  NETED  or  described  in  a  standard  SPICE  deck). 

•  Test  stimuli  (voltage  and  current  forces). 

•  Models. 

Outputs 

•  Data  array  containing  voltages  at  all  nodes  for  each  analysis  point. 

•  Charts  created  from  node  data 

Other  Data 

•  Commercial  product. 

Limitations,  Deficiencies,  Problems 

•  Slow;  simulation  time  increases  greatly  for  large  circuits,  circuits  with  feedback,  or  switching 
circuits  with  many  transitions 

•  Loading  analysis  is  not  a  built-in  function,  but  can  be  accomplished  by  manual  calculations  from 
analysis  results 

•  When  performing  functional  verification  and  power  dissipation  analyses,  the  user  must  manually 
look  at  every  component  and  check  the  results. 
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B3.3QUICKSIM 

Description 

QuickSim  is  an  interactive  logic  simulator  that  allows  the  verification  of  functionality  of  electronic 
designs.  The  design  must  be  captured  with  NETED,  a  schematic  capture  tool. 

Purpose 

•  To  verify  the  logic  functionality  of  designs. 

•  To  verify  circuit  timing. 

Analyses  Supported 

•  Digital  functional  verification  -  75%. 

•  Nominal  timing  verification  -  50%. 

Inputs 

•  Circuit  schematic  (captured  with  NETED). 

•  Test  vectors  (stimuli). 

•  Device  models. 

Outputs 

•  Signal  list. 

•  Signal  traces. 

Other  Data 

•  Commercial  product. 

Limitations.  Deficiencies,  Problems 

•  The  design  must  be  captured  with  NETED,  a  schematic  capture  tool. 
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B3.4  SABER 


Description 

SABER  is  an  analog  system  simulation  tool  for  electronic,  hydraulic,  mechanical,  and  other  systems. 
SABER  simulates  the  response  of  a  given  system  and  input  stimuli  for  DC,  transient,  and  frequency 
domains.  It  performs  several  types  of  analyses,  including  DC,  DC  sweep,  transient,  frequency  sweep, 
noise,  Fourier,  and  sensitivity,  and  has  a  graphics  interface  for  charting  analysis  results. 

Purpose 

•  To  simulate  and  verify  analog  systems. 

•  To  support  behavioral  level  modeling,  as  well  as  network  and  equivalent  circuit  modeling. 

Analyses  Supported 

•  System-level  functional  analysis  -  25%. 

•  Analog  functional  analysis -75%. 

•  Worst  case  analysis  -  25%. 

Inputs 

•  System  description. 

•  Test  stimuli. 

•  Models. 

Outputs 

•  System  outputs. 

•  Sensitivity  analysis  result. 

•  Fourier  results. 

Other  Data 

•  Commercial  product. 

Limitations,  Deficiencies,  Problems 

•  SABER  is  not  integrated  with  other  electronic  design  tools. 

•  Device  models  are  difficult  to  create. 

•  Graphical  interface  lacking. 

•  System  description  and  models  must  be  entered  as  text  files. 
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B4.0  PHYSICAL  DESIGN 


B4.I  BOARD  STATION 
Description 

Board  Station  is  a  physical  design  tool  for  printed  wiring  boards.  It  supports  automatic  layout  and 
routing. 

Purpose 

•  To  lay  out  and  route  printed  wiring  boards. 

Analyses  Supported 

•  Physical  board  layout  -  95%. 

•  Routing -50%. 

Inputs 

•  Component  connection  list. 

•  Parts  list. 

•  Physical  component  models. 

•  Board  description  and  specification. 

Outputs 

•  Physical  board  layout  and  routing. 

•  Layer  artwork. 

•  Assembly  and  abrication  drawings 

•  Drill  data. 

•  Layout  data  for  Package  Station. 

Other  Data 

•  Commercial  product. 

Limitations,  Deficiencies,  Problems 

•  Board  Station  does  not  support  simulation  tools  with  layout-dependent  data  for  analyses  of 
capacitance,  resistance,  and  cross-coupling  of  board  routes. 
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B4.2  INTERGRAPH  PWB  SYSTEM 


Description 

The  Intergraph  PWB  system  is  used  for  printed  wiring  board  and  printed  wiring  assembly  design, 
including  surface  mount  (SMT),  boards,  hybrid  packages,  discrete  wire  routing  (multi wire),  very 
large  PWB/PWA  boards,  and  combinations  of  these  technologies.  The  system  provides  interactive 
layout  of  components  and  connection  for  physical  design,  using  part  and  connection  data  extracted 
from  schematics  developed  on  other  tools  combined  with  physical  component  data  from  libraries. 

Purpose 

•  To  perform  automatic  or  manual  component  placement  and  optimization  and  autorouting  of  PWBs. 

Analyses  Supported 

•  Component  placement  -  90%. 

•  Routing -50%. 

Inputs 

•  Logic  schematic. 

•  Connection  list. 

•  Parts  list. 

•  Component  and  board  geometry  models. 

Outputs 

•  Layer  artwork. 

•  Assembly  and  fabrication  drawings. 

•  Back  annotation  schematic  data. 

Other  Data 

•  Commercial  product. 

Limitations,  Deficiencies,  Problems 

•  Maximum  file  size  of  300M,  15-layer  board  does  not  support  simulation  tools  with  layout 
dependent  data  such  as  capacitance  and  resistance  of  traces  or  cross  coupling,  etc. 
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B4.3  PACKAGE  STATION 


Description 

The  Package  Station  system  from  Mentor  consists  of  a  3D  CAD  drafting  tool  and  a  thermal  analysis 
tool.  The  drafting  tool  inputs  3D  package  designs  for  manufacturingor  input  into  the  thermal 
analysis  tool  of  EPAD.  The  thermal  analysis  tool  uses  layout,  cooling,  and  heat  generation  data  to 
compute  component  and  board  temperatures  over  a  2D  surface. 

Purpose 

•  To  input  3D  package  designs  and  compute  component  temperatures  for  failure  rate  analysis. 

Analyses  Supported 

•  Thermal  analysis  -  80%. 

•  3D  packaging  design  -  10%. 

Inputs 

•  Physical  board  design  (board  layout,  etc  ). 

•  Package  description  and  specifications. 

•  Component  data  (power  dissipations,  etc.) 

•  Cooling  specifications. 

Outputs 

•  Package  drawings 

•  Board  isothermal  maps. 

•  Component  temperatures. 

Other  Data 

•  Commercial  product 

Limitations,  Deficiencies,  Problems 

•  The  thermal  analysis  tool  currently  handles  only  2D  surfaces. 
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B5.0  RELIABILITY 


B5.1  MIREM 
Description 

The  MIREM  (Mission  Reliability  Model)  program  assists  in  the  evaluation  of  mission  reliability  and 
availability  tor  systems  incorporating  fault-tolerant  features  such  as  redundancy  and  dynamic 
n  configurability 

Pn rpose 

a  To  a>sist  in  the  evaluation  of  systems  incorporating  fault-tolerant  design  features. 

Analyses  Supported 

*  M  ission  and  system  reliability  -  80^0. 

*  Operational  availability  -  80^. 

a  puts 

*  System  functional  description 
®  Mission  scenario 

*  Reliability  and  maintainability  data  (e  g  ,  failure  rates,  repair  rates). 

••  fiitput.s 

»  >’  s 1 1 ■  .n ;  ( eliahiht.k  and  availability. 

■  M  r  Completion  Success  Probability  (MOSP) 

1  Meat.  Tune  Between  Critical  Failures  (MTBCF). 

-*  !•  a i lure  resiliency 

*  .'it  an  • ; me  between  maintenance  actions  l  MTBMA) 

< ) tber  Data 

9  Do!)  product 

i  imitations.  Deficiencies,  Problems 

't  Si/e  and  complexity  of  systems  that  can  be  modeled  is  limited 

®  l  imited  data  management  and  documentation  capabilities 

9  Not  integrated  with  existing  electronic  design  systems  or  analysis  tools 
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B5.2  AVIONICS  WORKSTATION  AUTOMATED  RELIABILITY  ESTIMATOR 


Description 

The  Avionics  Workstation  Automated  Reliability  Estimator  (AWARE)  provides  a  fully  automated 
capability  to  perform  MIL-HDBK  217E  stress  method  failure  rate  predictions  of  electronic 
equipment.  It  analyzes  a  single  assembly  selected  by  the  user,  with  results  available  for 
maintainability  and  system  reliability  analysis. 

Purpose 

•  To  predict  the  failure  rate  of  electrical  and  electronic  parts  and  assemblies  in  accordance  with  the 
stress  analysis  method  of  M1L-HDBK-217E. 

Analyses  Supported 

•  MTBF -90%. 

•  MTBDE-90% 

Inputs 

•  Electronic  parts  characteristics 

•  Temperature  of  components 

•  Electrical  stress  of  components. 

Outputs 

•  MTBF  of  parts. 

•  MTBF  of  assemblies 

Other  Data 

•  Boeing  product 

Limitations,  Deficiencies,  Problems 

•  Limited  to  a  single  circuit  board  at  a  time 

•  Assembly  failure  rates  cannot  be  accumulated. 

•  Serial  MTBF  computation  only,  redundancy  and  error  detection  are  not  considered 

•  Batch  only  operation,  no  interactive  interface 

•  Limited  to  Apollo  and  Mentor  workstations. 
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B5.3  COMPUTER-AIDED  RELIABILITY  MODELING  ANALYSIS 


Description 

Computer-Aided  Reliability  Modeling  Analysis  (CARMA)  is  a  general-purpose  program  for  mission 
reliability  modeling  and  prediction  of  complex  systems  It  is  one  of  a  family  of  standard  automated 
reliability,  maintainability,  and  availability  analysis  tools  being  developed  under  the  direction  of  the 
Boeing  Aerospace  Product  Support  organization. 

Purpose 

•  To  perform  a  reliability  prediction  for  each  subsystem  listed  in  the  system  configuration  data 

•  To  perform  global  predictions  on  all  listed  subsystems  or  selected  subsystem  predictions  based  on 
user  inputs 

•  To  calculate  system  reliability  on  a  per  mission  phase  basis,  including  dependency  from  one 
mission  to  the  next. 

Analyses  Supported 

•  Mission  reliability  -  50%  to  80^  . 

Inputs 

•  Installation  data 

•  Mission  phase  profile. 

•  Assembly  duty  profile 

•  System  configuration 

•  Assembly  failure  rates 

Outputs 

•  System  reliability 

•  Reports. 

•  Reliability  block  diagrams 

Other  Data 

•  Boeing  product 
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B5.4  COMPUTERIZED  EVALUATION  PROGRAM  FOR  RELIABILITY/AVAILABILITY 


Description 

The  Computerized  Evaluation  Program  for  Reliability/Availability  (CEPFRA)  solves  a  large  class  of 
reliability  and  availability  evaluation  problems  that  can  be  formulated  as  Markov  processes. 

Purpose 

•  To  solve  reliability  and  availability  evaluation  problems  where  the  underlying  failure  and  repair 
times  can  be  characterized  by  exponential  distribution. 

Analyses  Supported 

•  Reliability  -  60%. 

•  Operational  availability  -  60%. 

Inputs 

•  Failure  and/or  repair  rates. 

•  Initial  conditions  of  system  reliability 

•  Mission  time  for  reliability  and  point  and  interval  availability. 

Outputs 

•  Absorbing  process  -  reliability  and  MTBF 

•  Ergodic  process  -  availability 

•  Absorbing  process  -  availability 

Other  Data 

•  Commercial  product 

Limitations,  Deficiencies,  Problems 

•  Maximum  number  of  states  is  limited  to  30  on  the  mainframe  version  and  99  on  the  PC  version 

•  The  PC  version  does  not  produce  availability  outputs. 
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B5.5  RELCALC  2  AND  SYSCALC 


Description 

RelCalc  2  and  SysCalc  allow  definition  of  a  modular,  hierarchical  system  model  used  to  perform  the 
part  stress  reliability  prediction  procedure  of  MIL-HDBK-217D  and  E. 

Purpose 

•  To  provide  a  set  of  system-level  functions  that  allows  definition  of  a  modular,  hierarchical  system 

•  To  automate  the  part  stress  reliability  prediction  procedure  of  MIL-HDBK-217D  and  E. 

•  To  create  and  maintain  a  system  made  up  of  circuits. 

•  To  perform  the  system- level  reliability  prediction  calculations  for  the  current  system  and  output 
the  results,  including  system  failure  rate  and  MTBF  for  the  system  model. 

Analyses  Supported 

•  System  failure  rate  -  60%  to  75%. 

•  System  MTBF  -  60%  to  75% 

Inputs 

•  System  configuration  data. 

•  Parts  characteristics 

•  Parts  applications. 

Outputs 

•  System  failure  rate. 

•  System  MTBF 

Other  Data 

•  Commercial  product. 

Limitations,  Deficiencies,  Problems 

•  These  tools  are  limited  to  redundant  configurations  no  more  complex  than  K-of-N  identical  blocks 

•  There  is  no  provision  for  fault  coverage  input. 

•  Temperature  rise  must  be  input  directly. 

•  A  workaround  procedure  is  used  to  implement  217E 

•  Limited  to  a  maximum  of  50  modules,  except  K  may  range  to  500  in  a  K-of-N'  module 

•  Not  all  part  types  are  included  in  the  model. 
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B5.6  RELIABILITY  EFFECTIVENESS  ANALYSIS  PROGRAM 
Description 

The  Reliability  Effectiveness  Analysis  Program  (REAP)  provides  the  ability  to  perform  reliabi! 
predictions  based  on  the  techniques  and  data  contained  in  MIL-HDBK-217 

Purpose 

•  To  predict  failure  rates  for  components,  assemblies,  and  systems 

Analyses  Supported 

•  Reliability  -75%. 

•  Failure  rates -75%. 

Inputs 

•  MIL  HDBK  217  data 

•  Part  numbers  and  reference  designators. 

•  System  configuration  (drawing  tree) 

Outputs 

•  Assembly  failure  rate  breakdown 

•  System  configuration  tree. 

•  Failure  rate  versus  temperature  plot 

Other  Data 

•  Commercial  product. 
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B5.7  SINGLE-THREAD  RELIABILITY  OPTIMIZATION  PROGRAM 


Description 

The  Single-Thread  Reliability  Optimization  Program  (STROP)  optimizes  systems  design.  Starting 
w  th  a  single  thread  (nonredundant)  system,  it  sequences  redundant  additions  to  the  system  in 
accordance  with  the  maximum  ratio  of  incremental  improvement  in  system  reliability  with  respect  to 
the  incremental  increase  in  system  weight  (DIVDW).  STROP  also  predicts  the  weight  (or  cost) 
required  to  meet  a  given  reliability  goal  or  the  maximum  reliability  that  can  be  achieved  within 
given  weight  and  cost  constraints. 

Purpose 

•  To  perform  reliability  versus  weight  optimizations  on  defined  single-thread  system  configurations 
li  e  ,  long-term,  unmanned  spacecraft). 

Analyses  Supported 

•  Reliability  versus  weight  optimization  -  50%. 

Inputs 

•  Single-thread  component  block  identification. 

•  Block  configuration  and  number  of  components  in  block. 

•  Redundancy  addition  class. 

•  Failure  rates. 

•  Block  weight  and  redundancy  addition  weight 

•  Duty  cycle 

•  M  ission  time. 

•  Constraints. 

Outputs 

•  \l)<s:on  time  and  reliability  and  weight  constraints. 

•  System  cost 

Other  Data 

•  Boeing  product 
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B5.8  RPP 


V 


i 


Description 

RPP  provides  failure  rate  predictions  of  electronic  equipment. 

Purpose 

•  To  predict  the  failure  rate  of  electrical  and  electronic  parts  and  assemblies  in  accordance  with  the 
stress  analysis  method  of  MIL-HDBK-217E. 

Analyses  Supported 

•  MTBF-70% 

•  MTBDE-70%. 

Inputs 

•  Electronic  parts  characteristics. 

•  Temperature  of  components. 

•  Electrical  stress  of  components. 

Outputs 

•  .VfTBF  of  parts. 

•  MTBF  of  assemblies. 

•  MTBDE 

Other  Data 

•  Boeing  product. 
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B5.9SINDA 


Description 

Sinda  is  a  general-purpose  thermal  analysis  program  that  is  based  on  a  3D  finite  difference  model 
supplied  by  the  user.  It  analyzes  conduction,  convection,  and  radiation  modes  of  heat  transfer  as  well 
as  incompressible  fluid  flow  in  ducts.  A  finite  difference  model  representative  of  the  physical  entity  is 
required.  The  model  must  define  the  finite  difference  nodes,  their  thermal  connectivity,  and  thermal 
conductance  values. 

Purpose 

To  analyze  the  complete  domain  of  heat  transfer  situations  encountered  in  electronic  equipment. 

Analyses  Supported 

•  Steady-state  thermal  analysis  -  100%. 

•  Transient  thermal  analysis  -  100%. 

Inputs 

•  Thermal  model 

•  Cooling  specifications 

•  Circuit  description. 

Outputs 

•  Nodal  temperatures. 

•  Conductance  values. 

Other  Data 

•  Public  domain  program  developed  by  NASA. 

Limitations,  Deficiencies,  Problems 

•  Because  Sinda  supports  incorporation  of  user-supplied  Fortran  code,  it  is  limited  only  by  the  user 

•  Sinda  does  not  support  graphics  input  or  problem  definition 

•  This  tool  requires  development  of  finite  difference  thermal  models  that  incorporate  design 
parameters  for  tailoring  the  model  to  a  particular  physical  instance  of  the  entity  for  which  the 
model  was  created 
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B5.10  THERMAL  EFFECTIVENESS  ANALYSIS  PROGRAM 


Description 

The  Thermal  Effectiveness  Analysis  Program  (THERMAL)  predicts  thermal  characteristics  of  circuit 
boards  and  analyzes  the  board  for  convective  heat  transfer  to  predict  component  and  junction 
temperatures. 

Purpose 

•  To  predict  electronic  component  temperatures  on  circuit  boards. 

Analyses  Supported 

•  Thermal  (convective)  -  80%. 

Inputs 

•  Physical  layout 

•  Power  dissipation. 

•  Cooling  data 

Outputs 

•  Component  temperatures. 

Other  Data 

•  Commercial  product 

Limitations,  Deficiencies,  Problems 

•  THERMAL  is  restricted  to  convective  heat  transfer,  which  is  insignificant  in  avionics. 
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B5.ll  AUTOTHERM  (MENTOR  PACKAGE  STATION  TOOL) 


Description 

Autotherm  is  a  thermal  analysis  tool  integrated  with  Mentor  Package  Station.  It  uses  layout, 
cooling,  and  heat  generation  data  to  compute  component  and  board  temperatures  over  a  2D  surface. 

Purpose 

•  To  compute  component  temperatures  for  thermal  and  failure  rate  analysis. 

Analyses  Supported 

•  Thermal  analysis  -  80% . 

Inputs 

•  Physical  board  design  (board  layout,  etc  ). 

•  Package  description  and  specifications. 

•  Component  data  (power  dissipation,  etc  ). 

•  Cooling  specifications. 

Outputs 

•  Board  isothermal  maps 

•  Component  temperatures. 

Other  Data 

•  Commercial  product. 

Limitations,  Deficiencies,  Problems 

•  Currently  handles  only  2D  surfaces. 


i 
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B6.0  MAINTAINABILITY 


B6.1  AUTOMATED  MAINTAINABILITY  ANALYSIS  PROGRAM 
Description 

The  Automated  Maintainability  Analysis  Program  ( AMAP)  is  an  application  of  the  SMART  software 
package  that  helps  automate  maintainability  analysis. 

Purpose 

•  To  input,  organize,  and  store  maintenance  data. 

•  To  structure  the  data  entered  and  create  an  electronic  worksheet  that  allows  the  user  to  calculate 
the  MTTR  and  Mmax  and  to  create  corrective  maintenance  timelines. 

Analyses  Supported 

•  MTTR -80%. 

•  Mmax -80%. 

Inputs 

•  Description  of  system. 

•  Location  of  maintenance  action 

•  Quantity  of  identical  SRL’s  used  in  the  assembly  or  LRU. 

•  Failure  rate  for  SRU 

•  Additional  inputs  dealing  with  corrective  maintenance. 

Outputs 

•  MTTR 

•  Mmax 

•  Corrective  maintenance  timeline. 

Other  Data 

•  Boeing  product 

Limitations,  Deficiencies,  Problems 

•  AMAP  must  be  tailored  to  each  project  by  changing  code. 

•  Only  one  assembly  can  be  calculated  at  a  time. 

•  The  program  does  not  accumulate  system  estimates 

•  There  are  a  maximum  of  25  subtasks  per  SRU  record. 
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B6.2  MAINTAINABILITY  EFFECTIVENESS  ANALYSIS  PROGRAM 


Description 

The  Maintainability  Effectiveness  Analysis  Program  (MEAP)  performs  serviceability  evaluations  on 
electronic  and  electromechanical  systems  based  on  MIL-HDBK-472. 

Purpose 

•  To  perform  MTTR,  mean  downtime,  and  maximum  corrective  maintenance  calculations  at  each 
maintenance  level. 

Analyses  Supported 

•  MTTR -75%. 

•  Mean  downtime  (MDT)  -  75%. 

•  Maximum  corrective  maintenance  (Mctmax)  -  75%. 

Inputs 

•  System  description. 

•  MIL-HDBK-472  data. 

Outputs 

•  MTTR 

•  Mean  downtime  (MDT). 

•  Maximum  corrective  maintenance  time  (Mctmax). 

Other  Data 

•  Commercial  product 


B6.3 GENERALIZED  RELIABILITY  AND  MAINTAINABILITY  PROGRAM 


Description 

GRAMP  is  a  set  of  computer  programs  for  modeling  fault  tolerant  complex  systems,  allowing  for 
repair. 

Purpose 

•  Reliability,  maintainability,  and  availability  predictions  to  support  allocations  and  evaluations. 

•  LSA/LCC  analysis. 

Analyses  Supported 

•  Markov  model  used  as  basis  for  reliability,  maintainability,  and  life  cycle  cost  analysis. 

Inputs 

•  System  description  and  architecture  (e  g.,  block  diagrams). 

•  Failure  rates,  repair  times,  etc. 

Outputs 

•  Reliability,  availability,  block  diagrams 

Other  Data 

•  Commercial  product 

Limitations,  Deficiencies,  Problems 

•  Size  and  complexity  of  systems  that  can  be  modeled  is  limited. 

•  Limited  data  management  and  documentation  capabilities. 

•  Not  integrated  with  existing  electronic  design  systems  or  analysis  tools. 
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B7.0  TESTABILITY 


B7.1  COPTER 
Description 

Copter  is  an  observability  and  controllability  analyzer  for  ASICs.  The  ratings  can  be  used  to  assess 
the  work  required  to  increase  design  testability. 

Purpose 

To  determine  the  observability  and  controllability  of  an  ASIC  for  testability. 

Analyses  Supported 

•  Testability  -  10%. 

Inputs 

•  Circuit  description. 

Outputs 

•  Observability  and  controllability  ratings 

Other  Data 

•  Commercial  product. 

Limitations,  Deficiencies,  Problems 

•  Copter  works  only  for  ASICs  designs 


226 


B7.2  QUICKFAULT 


/ 


Description 

QuickFault  is  an  interactive  simulator  that  can  operate  as  a  fault  simulator  or  as  a  logic  simulator 
In  fault  mode,  it  is  an  interactive,  concurrent  fault  simulator  that  allows  grading  a  set  of  test  vectors 
to  determine  how  effectively  they  detect  and  isolate  faults. 

Purpose 

•  To  test  how  effectively  a  set  of  test  vectors  detects  and  isolates  faults  or  defects  in  a  digital  circuit 

Analyses  Supported 

•  Fault  detection  and  isolation  -  90 °!c 

•  FMA-50%. 

•  FMEA-50% 

•  FMECA-50% 

•  FTA-30%. 

•  Testability  -  25%. 

Inputs 

•  Circuit  description 

•  Test  vectors  (stimuli). 

•  Fault  list 

Outputs 

•  Fault  dictionary 

•  Detection  list 

•  Detection  statistics 

Other  Data 

•  Commercial  product 

Limitations,  Deficiencies,  Problems 

•  Not  sufficiently  robust  for  large  scale  designs 
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B7.3  T3 


Description 

T3  is  a  topological  testability  checker  that  checks  a  design  for  a  limited  number  of  topological 
testability  design  rules  and  gives  error  messages,  noting  areas  that  violate  the  design  rules. 

Purpose 

To  check  a  design  foi  testability  and  show  errors 

Analyses  Supported 

•  Testanility  -  10%. 

1  nputs 

•  Circuit  description 
Outputs 

•  Testability  rules  not  followed. 

Other  Data 

•  Moeiug  produc' 

Limitations,  Deficiencies,  Problems 

•  I ) ; 1 1 ;.  : opnlogica I  le-  ’ability  rules  are  oiiecki  d 

•  Limited  mirdvr  of  testability  design  rules 
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B7.4  WIRING  INFORMATION  AND  RELEASE  SYSTEM 


Description 

The  Wiring  Information  and  Release  System  ( WIRS),  an  IMS  system,  accummoda  <  ~  ‘he  definition  of 
wiring  systems.  It  develops  automated  tests  and  electromagnetic  pulse  ana !>  sis  !'.r  wiring  hundles. 

Purpose 

•  To  integrate  the  design/build  process 

•  To  control  the  release  of  information  used  for  the  design,  nianufact  are.  ins»ai!atio:i,  and  testing  of 
airplane  wire  bundles 

•  To  develop  tests  and  perform  analyses 

Analyses  Supported 

•  Wiring  test  generation  -  90^. 

•  Electromagnetic  puise  analysis  -  100^ 

Inputs 

•  Wire  bundle  assembly,  diagram,  and  equipment  data 

•  Mockupdata. 

•  Planning  data. 

Outputs 

•  Test  for  manufacturing  tester. 

•  Pulse  analysis  results. 

•  Design  and  planning  error  diagnostics 

•  Shop  aids,  reports,  and  materials 

•  Installation  instructions 

Other  Data 

•  Boeing  product 
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B8.0  DOCUMENTATION  PREPARATION 


B8.1  GENERAL  PURPOSE  DOCUMENTATION  PROGRAMS 
Description 

General-purpose  documentation  programs  can  be  employed  to  document  the  results  of  any  task  or 
analysis. 

Purpose 

•  Documentation  preparation. 

Analyses  Supported 

«  All 

Inputs 

•  Tabular  data. 

•  Textual  data. 

Outputs 

•  Documentation. 

Other  Data 

•  Commercial  products. 

Limitations,  Deficiencies,  Problems 

•  Not  integrated  with  existing  design  systems  or  tools,  manual  management  and  formatting  of 
information  required. 
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B8.2  MENTOR  DOC  PROGRAM 
Description 

DOC  is  a  general-purpose  word  processor  and  document  editor. 

Purpose 

•  To  prepare  reports  and  other  forms  of  documentation. 

Analyses  Supported 

•  Documentation  -  90%. 

•  Reports  -  90%. 

Inputs 

s  Text 

•  Graphics. 

Outputs 

•  Documents. 

•  Reports 

•  Tables. 

Other  Data 

•  Commercial  product. 

l  imitations.  Deficiencies,  Problems 

•  Graphics  must  be  in  a  Mentor  format. 
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B9.0  GENERAL  PURPOSE  SPREADSHEET  PROGRAMS 


Description 

General-purpose  spreadsheet  programs  can  be  programmed  to  compute  many  of  the  design 
parameters  required  as  part  of  the  design  analyses  described  in  Appendix  A. 

Purpose 

•  General  purpose  computing  support  for  a  variety  of  design  tasks  and  analyses. 

Analyses  Supported  (examples) 

•  LCC  optimization  -  20%. 

•  FMECA-20%. 

•  Reliability  -  50%. 

•  Failure  rate,  MTBF,  MTBDE  -  70% 

•  Maintenance  timeline,  MTTR,  Mmax  -  40%. 

•  FD/FI  - 10%. 

•  FRACAS- 15% 

Inputs 

•  Tabular  data. 

•  Algorithms. 

Outputs 

•  Tabular  data. 

Other  Data 

•  Commercial  products. 

Limitations,  Deficiencies,  Problems 

•  Not  integrated  with  existing  design  systems  or  tools,  manual  management  and  formatting  of  data 
required. 

•  Available  tools  have  limited  representation,  analysis,  documentation,  and  data  management 
capabilities. 
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